Text 760, 63 rader
Skriven 2007-03-24 22:45:28 av Maurice Kinal (1:140/13)
    Kommentar till text 759 av mark lewis (1:3634/12.0)
Ärende: lossey Fido
===================
Hey mark!

Mar 24 17:48 07, mark lewis wrote to Maurice Kinal:

 MK>> The pkt and msg headers.  They only serve to slow down tossing

 ml> i'd like to see and hear a bit more of your ideas on this, maurice...

I have a preliminary script I am working on.  I'd be happy to send it your way
for your approval.  Basically all it does is strip the unneeded headers from
raw incoming pkt's and store the result to a file with the same name as the
incoming raw pkt with a new extension.  The messages each take up exactly one
line of the resulting archive.  So far all it requires is sed, hexdump, dd and
echo.  I needed hexdump to reformat the regexp for sed to properly strip out
the message headers which are always 14 bytes but other then the first message
in the raw pkt it is difficult to determine where any further messages header's
are within a raw pkt.  The pkt header is easy since it is always at the
beginning.

I can see this strategy working for other's, even the hypertext people, and
would suggest that if the raw format followed what the result of the above is
we'd all have had far less problems.  I left the kludges in there along with
the control code they seem to want and can see where a proper null delimiter
would easily fit in to seperate fields now that all the null padding has been
tossed to the bitbucket where exactly they should have been sent by the
original tosser.  ;-)

Should be fairly straight forward to take the result and reformat it to
whatever target, even html.

 ml> the biggest problem i see with existing formats is implementing them 
 ml> in "arcane" "languages" like perl, php, python and others that do not 
 ml> embrace binary data easily...

What binary?  If you mean the headers those get farmed out to the bitbucket
since they contain no useful information to machine nor beast.

 ml> the thing that i'm looking at is the ability for existing mail 
 ml> tossers to look at a series of bytes in the header at a specific 
 ml> offset to determine the PKT type so that they can either process or 
 ml> ignore the PKT...

Hm.  I have yet to find anything in any PKT type that is of any consequence.

 ml> the worst thing with existing fidonet PKTs and packed messages is the 
 ml> placement of the PATH and SEENBY lines... they should be at the top 
 ml> with the other information... also, the lack of the ORIGIN address 
 ml> being required to be in the PATH line causes some troubles...

One step at a time.  Currently I am leaving all that alone and is still in the
result.  However all that is readily identifiable which is the real bonus of
doing it this way.

 ml> anyway, there are numerous proposals in existance that have never 
 ml> gone anywhere... at least, IIRC, it actually a text based format ;)

ascii at the moment.  It probably would be nice to overcome that limitation.

Life is good,
Maurice

--- Msged/LNX 6.2.0
 * Origin: Coffin Point BBS (1:140/13)