(Continued from previous message)


In fact netmail in QWK is even more of a monster kludge than it is
in PKT. There is nowhere to put the destination at all. Your To: style
is just ONE approach thats used in QWKs. And even that is fucked too.
Classic kludge.

BL> QWK is a bit queer with its ndx files. Knowing the position
BL> of each message in a conference makes it easy to sort, but
BL> the essential data is in the headers anyway.

Thats right and some QWL readers will make the NDXs for you if they
are missing. They are mostly there just because thats how the PCBoard
online message base works. Its a speed thing for stepping thru a message
base in a particular area. Usual index justification.

BL> Processing the ndx is surprisingly fast (it surpised me, anyway),
BL> and they take up very little room.

Yeah, and make a vast difference in a mail reader.

BL> On the whole, I think I prefer QWK as being more robust,

Yes, but pathetically inadequate on expandability.

BL> but like PKT format it lacks room for seenby and path,

Yep, some stuff like that is just hopeless for a fixed format.

BL> and the 128-byte header is full up. Its problem is that with
BL> multiple QWKs, you are odds-on to get the control.dats and ndx
BL> files mixed up!

And you have a very very fundamental design limitation that if the BBS
its generated from changes its areas around in the message base, the
numeric based areas breaks very badly. If you download a QWK and the
BBS redoes its message base before you upload the REP, you are fucked.

BL> At least PKT is self-contained.

Yeah, that single file approach can be much simpler for stuff like
combining them.

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

BL> Yes... but I think any new system ought to be able to handle
BL> graphics. The NAPLPS stuff meant for Teletext looks good to me.

NAPLPSs is a very old graphics format now. And hardly used on PCs
at all, a very significant disadvantage. And you have to seriously
consider a much more fundamental question of whether you want a
vector based or a bit mapped style format anyway. Or both.

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.

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

BL> Har! That's quite right, but the only use for SOT and EOT is when
BL> none of the others are there.

Nope, when its widely used, it makes working out what is user text much
simpler.

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

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

BL> What's the reason then? I've never seen an explanation that made
BL> any sense.

The basic idea is that it was thought that you need BOTH soft and hard
CRs. Primarily to allow the message to be independent of the users screen
width. So you could read it on say 40 col screens. You need to make a
distinction between soft and hard CRs to be able to reformat the message
to fit on the screen the user is using.

As a general principle its still valid, coz the last thing you want to
do is rewrap a quoted para, it becomes close to unreadable if you do.

Corse you could NOW just said that the user had better have atleast an
80 column screen or if he doesnt HIS reader can worry about how to use
a say 60 col screen. In other words its rare enough that the message
format doesnt need to worry about that rare situation.

OTOH once you have both hard and soft CRs, you can sustain an argument
that its pointless to take them out now. Particularly as wps etc do use
that concept all the time. If they are there, something can use them.
If you have collapsed the design so there is only one CR, you cant be
definition reverse that if you need to without lots of guesswork.

BL> It certainly gets stuffed up, if another editor adds its own CRs
BL> and re-wraps the existing text.  If the Pi-copnversion is meant to
BL> prevent that, it doesn't work.

Sure. And the other thing is that the message format really crys out for
a more formal specification of quoting. Far too much guesswork involved
now and most message software decides it all too hard and doesnt bother
and you get fucked abortions of unreadably quoted paras.

--- PQWK202