Text 297, 61 rader
Skriven 2005-03-27 12:42:16 av mark lewis (1:3634/12)
    Kommentar till text 295 av Maurice Kinal (1:261/38.9)
Ärende: perl before swine
=========================
 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)