KR> did you ever think though bob, that the world ain't all
KR> readers. the software that actually moves the messages
KR> around would be a lot simpler if sot/eot was mandatary.

BL> I agree totally. But it isn't mandatory, is it? At best, we
BL> will have a mixed system of readers and mailers not sot/eot aware.

Yes, thats life when the original specs were pretty fucked.
Says nothing useful about the advantages of having SOT/EOT
get gradually adopted and the advantages of having the bulk
of messages adhere to the SOT/EOT spec so you can deal with
messages which have them cleanly and elegantly and have the
separate messy, less than totally reliable, and intrinsically
slow, alg used ONLY when the message DOESNT have the SOT/EOT.

If the bulk of messages use SOT/EOT strictly,
you have moved forward into a better situation.

Just like it took the use of MSGID quite some time to get up a decent
head of steam, but it now is used in the vast bulk of messages, and that
is a very worthwhile bit of progress for say dupe detection. Yes, you do
need to deal with the messages which DONT have a MSGID as a special case,
BUT when the vast bulk do, its a worthwhile advance for dupe detection.

BL> Even better, make the Tear line mandatory, or Origin line.

Making something mandatory is harder. Yes, that should have been
done initially, a rigid specification of that pair and mandatory.

Even then, its a lot easier to find an EOT than the more complex
pattern of the tearline/origin pair and its associated stuff like
blank lines and CRs etc even if it had been rigidly specified and
mandated. For a bit of code that just wants to see what is user
text so it can hand that out to a quoter when the user is replying,
it may well STILL simplify the code very considerably if it just
has to find the stuff between the SOT/EOT pair and maybe even not
try very hard on the trailing stuff on the end of the message when
there isnt an EOT coz the user can see whats clearly crap anyway.

Atleast that approach of an SOT/EOT pair would mean that there is
no good reason for a message reader to quote anything outside it,
even if the author couldnt be bothered farting around detecting
the rigidly specified and mandated tearline/originline and leaves
it to the user to delete with the inevitable result that lots of
users dont bother and arent even aware that its desirable to do so.

KR> since that isn't really likely at this stage of fido's
KR> existance, it should also be noted that that software would
KR> handle any sot/eot messages in the normal message stream
KR> faster by simply ignoring anything between sot and eot.

BL> How? It has to find EOT, and by then it's too late...
BL> it's already scanned the entire message to find it!

Poor old Bob, clearly still at the stage where he knows so little
about programming that he isnt even aware of how ignorant he is.

Its one HELL of a lot simple for something that attempting to work out
when the user text is to scan for SOT, then if it find it, scan for EOT,
and whats between them is user text, than to have to fart around backing
up from the null at the end of the message to what looks like it might
be the end of user text, and strip all the crap off the top that looks
like kludge lines too. In a decent awk like language, you can even do
the whole fucking thing in a SINGLE line of code and fall thru to the
shitty long winded way when there aint no SOT/EOT pair in the message.

That would be just as true of a message base system that goes
the whole hog of separating out the real user text from the
message as it tosses all mail into a real database, putting
ALL the control stuff thats not user text into appropriate fields,
even if they are pseudo user text at the end of the message. A
significant percentage of the messages using SOT/EOT will see the
rate of tossing messages into the database hike up well above what
it would be if you just do it the longwinded way on every message.

BL> Nice theory, though...

Nice practice too. Poor old Bob.

BL> The only way to do that is to define the length of the message
BL> in the header like QWK does... *then* you can skip to the end.

BL> It would be quite easy to go through FTS-1/4 and fix it.

Yes, pity the problem arises with the messages that no longer
comply with your new FTS-1/4. You clearly havent got a fucking clue
whats involved in how you move forward from rather fucked specs Bob.

BL> It was written when ascii was all anyone wanted to send, but
BL> it's ended up with a packet header that's too big, a message
BL> header that's too small, a mixed text window of #1 and ascii control
BL> lines, and no specification to say what may or may not be sent.

Yes, they fucked it up considerably initially. Pity that was fucking
years ago and there is nothing we can do about that fuckup now.
@EOT:

---