Subj : perl before swine To : Maurice Kinal From : mark lewis Date : Sun Mar 27 2005 12:42 pm MK> Please excuse the quotes etc. as I am still hacking and havve MK> altered my plan dramatically from where this started. Decided MK> to go with the point setup as it is more a singleuser MK> DOS-think thingy and thus might be a better approach for Fido MK> schtuffenputten ... for now. We'll see. not a problem... ML>> you need to stop and realise/remember that the format is taken from ML>> the actual local message storage format just like QWK stuff is taken ML>> from the PC Board message base format... MK> Understood. This is a HUGE problem when thinking along the MK> lines of a Linux multiuser app, as it is unlikely the format MK> of the local bases would be simular to a singular thinking MK> uplink. i should have been more clear and stated "taken from the original local message storage format *.MSG"... my local message storage formats doesn't look even remotely close the *.MSG ;) MK> It has proved to be a stumbling block and hence my MK> comment about it to Rusty. From a sysop's point of view, MK> using Linux as the OS of choice, the local storage REALLY MK> needs a major overhaul. As a Linux point it could stand some MK> alterations but it isn't as big of a deal given a more MK> singular perspective of the traditional Fido point useage (ie MK> not a multiuser BBS). you could use MBOX format for local storage if you want to... as long as the packed messages in the PKTs and the PKTs conform to current standards... heck, you could even go as far as implementing a type 3 PKT format that you use between you and your hub... there are a couple of type 10 PKT formats that are documented, too ;) ML>> it is a tad bit harder to handle the control lines at the end of the ML>> messages... not all that much harder but still harder, anyway... MK> I still think a suitable filter between the node - the MK> multiuser Linux BBS - and the rest of the world - the uplink - MK> is the way to go. Treat the local setup more Unixie without MK> any regard to DOS-think or traditional FTN formats and let the MK> filter between the BBS and the uplink worry about FTN MK> formatting. From what I've seen thus far that seems to make MK> the most sense. It is defintely more difficult to alter Linux MK> to think more DOS-like and hence more FTN-like unless you have MK> some insight there you'd care to share. not about altering anything however a new packet format with tosser sounds interesting ;) possibly one that converts outside type 2 pkts to mbox formatted type 3s to feed to your downstream users/machines running linux... remember, today's tossers look in one or two places for a binary signature indicating the PKT type so that's about the only "binary" type stuff that i could see possibly needing to be maintained if at all... one could consider this type 3 tosser as the "filter" that you speak of above ;) )\/(ark * Origin: (1:3634/12) .