(Continued from previous message)

Sure, thats always been something that its taken the amateur industry
a while to really get their brains around, the designs tend to be done
so the are relatively efficient at the uncompressed level when in fact
that doesnt matter much at all, its the compressed which matters.

It would actually be quite interesting to do some tests and see if
there really is any point in the CONTROL.DAT having area names in it.
Thats obviously been done so there isnt one long one in each message,
just a shorter number. It may well be that after archiving it doesnt
matter a stuff coz they are so repetitive anyway and the archiver will
do that anyway.

BL> I'd use the fixed 128-byte fields of QWK (less ndx),
BL> coupled to the more clever non-ascii header of PKT.

There isnt all that much in it with the user text proper whether
its done with fixed fields padded on the end or a delimited variable
length field. The specified number of fixed 128 byte fields is just
another way of specify the length of the user text so it can have
anything at all in it. But you could have the user text variable
length with the actual number of bytes in the user text specified
instead, no need for fixed fields.

And you can even argue that if you are going to do a whole new message
format, you really need to consider why its not better to use one of
the database formats. Coz they should be stored at each end like that
anyway, so whats the point in something different in the packets which
are transported between them ?  Not much basically.

RS> The SOT EOT approach allows totally unambiguous delimiting of user
RS> text which can be complete ignored when looking for header data.

BL> Using the AREA line and the Origin line does exactly the same thing.
BL> Write the code and you'll see. You end up with exactly the same code,
BL> dupicated. Just eliminate SOT and it works the same; eliminate EOT
BL> and it's better! That was what I finally did.

You are utterly confusing what you have to do when the SOT and EOT
are added later to what the code would be like if they had been there
in the beginning. Of course you have to do that when hardly anyone is
using SOT EOT now, like I said.

RS> Even thats not right. You process thru the header detail at the top,
RS> picking up what you want to use header details wise. You hit the SOT,
RS> you just then keep skipping lines till you hit the SOT and then you
RS> can look for more header details.

BL> That's what I mean by "reading right through." In my final program,
BL> it takes 30mS to convert a message. 15mS of that is spent converting
BL> the PKT cr's to Pi in QWK. 5mS is spent erasing SOT and EOT, or their
BL> little ^a friends.

This is where you are having a brain fart. You have to drop all the
other kludge lines anyway. It takes no longer to drop SOT and EOT TOO.

BL> The guts of it takes 10ms, writing ndx files and all! In converting PKT
BL> to QWK, you use hardly any header detail; just date/time, To, From, and
BL> subject. It breaks my heart to waste so much time dodging kludges.

All utterly irrelevant to the question of whether the SOT and EOT have
some value if they were widely used. And you have it wrong anyway on the
current situation where they arent, you just extract the user text as its
always been done, if it happens to have an SOT at the start and and EOT
at the end, drop them. Or just drop all kludge lines. No big deal at all.

BL> What the point of converting the CR's to Pi, anyway? I'm
BL> tempted to leave it out, and send the QWKs with embedded cr's.

Its a rather more complicated question that it looks. Some QWK readers
do use them sensibly. There is a difference.

--- PQWK202