Text 759, 57 rader
Skriven 2007-03-24 17:48:50 av mark lewis (1:3634/12.0)
    Kommentar till text 747 av Maurice Kinal (1:140/13)
Ärende: Hypertext Fidonet (Fidonet Global Hypertext Interchange)
================================================================

 MtW> proposal). Which of those would you consider no longer relevant, and 
 MtW> burdening?

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

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

i can easily see where something akin to internet email and newsgroup header
format would be easier to implement in some cases but there is some information
in those headers that is necessary... i can't see just tossing them out
completely would really help...

another (difficult?) problem would be in how to determine this new "PKT"
type... existing PKT formats along with the TYPE 3 and TYPE 10 proposals
provide a method that (IIRC) coincides easily with the existing TYPE 2
formats...

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

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

i have a pascal (yeah yeah yeah) tool that reads the binary PKT header (a block
of 58 bytes) into memory and then uses absolute addressing to overlay the
formats for FTS-0001, FTS-0039 and FTS-0045 on that 58 byte block to determine
which PKt format is being used... once that is known, then other information
can be extracted from the _packet_ header to be used while processing the
messages contained inside that PKT file...

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

i mention those things in that paragraph because they are the main reasons why
the arbitrary limits on message size have appeared in fidonet quite contrary to
what FTS-0001 states with regard to message bodies being _unbounded_... hobby
coders who developed much of fidonet software just didn't take the time or have
the wherewithall to figure out how to process messages larger than 64k since
that was the limit of the main OS and standard compilers being used during the
developmental days of fidonet... with this arse-end info being at the top and
included within the header, it would have made things a lot easier and we'd
likely not have these limits anywhere other than in the offline message reader
world (some have =line= limits!) or possibly in the BBS packages used...
however, i also submit that the BBS world would likely have had an easier time,
too...

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

)\/(ark

 * Origin:  (1:3634/12)