(Continued from previous message)

buckleys.

BL> I would set up a fixed header with spare fields for expansion,
BL> and that's it!

RS> That approach doesnt work because it inevitably breaks when you
RS> have exhausted that fixed header. Thats precisely the problem
RS> with the current QWK format, its fixed, its not readily expandable.

BL> QWK relies on fixed 128-byte records right through the packet.

Yes, and its crippled by that on expansion of the format.

BL> I only want a fixed messager *header*.

And its the header which cripples you on expansion if you do the header
like that.

BL> It would be easy enough to build expansion into that header.

Not if its fixed as you said you wanted. Spare fields dont work for
long. QWK started off with spare fields, it is fucked expansion wise.

BL> My idea is to use the last "Subject" field that precedes the
BL> message field; expand it, delimit it with ordinary CRs to add
BL> the extra fields at the end, and then fix it with plenty of
BL> spare room up front padded with spaces that compress well.

Its still a fixed header which fucks your expansion possibilitys.

BL> The necessary origin line would be constructed from one of the
BL> header fields,

RS> Thats got some advantages for the fixed fields in it, the node
RS> details, but doesnt help with the rest.

BL> The "rest" has to come from the mailer cfg file, which actually
BL> writes the header anyway. This is the *message* header.

And since its fixed, its fucked.

BL> Most of it comes from the original mailer. Only the seenby
BL> and path lines would vary as the message goes the rounds.

And that stuff cant possibly be fixed anyway, so there is another
area where fixed header stuff cant work. QWK doesnt bother to even
store that stuff so it isnt a problem for it.

RS> AND your idea isnt readily usable in tandem with the current
RS> system anyway. Yes, its possible to design a whole new message
RS> format from scratch, but we arent looking at one of those and
RS> how to do it, we are actually looking at something which can
RS> enhance and be used with the current one.

BL> I agree. It has to be backwards compatible, like colour TV.

And you design isnt.

BL> Old mailers would work with the new header.

Nope.

BL> All we do is lengthen the "Subject" field.

You cant do that. The approved expansion route is the ^A kludge lines.

BL> The extra stuff goes on the end, delimited by CRs.

Adding YET ANOTHER DIFFERENT way of delimiting header type fields
in what is already a format which has FAR TOO MANY different ways
of doing that. What a fucking abortion Bob.

BL> Old mailers wouldn't even know.

Crap.

BL> New mailers would write both the new header and the old kludge,
BL> but old mailers would break high ASCII, control codes, and graphics.

And you have an utter abortion of a format, no thanks.

RS> Coz a whole new one from scratch has buckleys of ever
RS> getting everyone switching to it. And if you are going
RS> to make a complete step away from the current one, you
RS> first have to show that one of the true standards like X.400
RS> isnt usable. No point in generating a whole new one if it is.

BL> It would have to be Type-2 compatible.

And it isnt.

BL> An entirely new standard would be the preferred option,

Crap, using a suitable CURRENT standard like X.400 would be FAR better.

BL> but these things have to happen slowly, in stages...

Your approach wouldnt happen at all, the net would yawn and take no notice.

BL> either that, or a completely new net.

Thats been tried too, that doesnt work either.

RS> It would actually be quite interesting to do some tests and see if
RS> there really is any point in the CONTROL.DAT having area names in it.

BL> QWK identifies the message AREA with a simple binary number that
BL> is just two bytes, but you need to carry the conversion list in
BL> the packet whether the whole list is used or not, or establish a
BL> unique number for each AREA, world-wide.

Thats supposed to be news ? Its done like that as an alternative to
putting the area text in each message, in theory being more efficient.
I was saying that it would be interesting to test if it really is. Coz
if its not, its certainly easier in the code if the message itself has
the area text in it for a lot of message processing code.

BL> PKT uses "AREA:LOCUSER" which takes up 12 bytes per
message, regardless.

Yes, and thats a whole new can of worms, the length is pathetic.

BL> If your average is 100 messages, that's 1200 bytes for AREA in
BL> PKT against 200 in QWK, and a typical control.dat is 350 bytes.

The point tho is that an archiver which uses dictionary style compression
should atleast in theory get those area names into the dictionary and
replace them with a number in the compressed text. In other words that
is done in the archiver instead of in the message format design.

BL> But who gives a shit? We're talking about 1000 bytes in 100Kb.

Well, to some extent you really need to consider the pathetic 12
byte size too if you are looking at the fundamentals of the design.

The real reason its done like that with QWK is that QWK is essentially
just a dump of the PCBoard online BBS message base, a subset of it,
the messages you want. It wasnt designed specifically for passing mail
between systems at all.

BL> Processing time is about the same.

Depends on what you are doing to the messages.

BL> I prefer QWK because it defines netmail as just another area. PKT is
BL> a bit shaky on netmail, and the AREA: kludge spoils the message field.

(Continued to next message)

--- PQWK202