BL> BTW, how do you know where to add your EOT? Read the
BL> Tear line, do you? If that's the case, what's it doing
BL> that the Tear line doesn't do? Your EOT logic is loony.

FM> Actually, that's a very good point. If an automated
FM> process can determine where to place a SOT/EOT pair,
FM> then by trivial proof a SOT/EOT pair ain't necessary.

RS> You've had a brain fart. That doesnt apply to what is CREATING the
RS> message, say taking what an external editor hands it as user text,
RS> bracketing that with the SOT/EOT pair, and THEN doing whatever it
RS> chooses to with control info outside the block of user text its not
RS> concerned with. Its just as true if its got an internal editor too.

FM> Yeah, I appreciate that. If you're the original creator
FM> of the message you know where to stuff the SOT/EOT.

RS> And THATS what the SOT/EOT is about, the original creator
RS> of the message. Avoiding producing a message which can
RS> cause problems with stuff like embedded origin lines etc.

FM> Yes, I know that. But...

FM> But Paul is presumably doing so, by an automated
FM> process (I don't *think* he's personally inside my
FM> computer) in QWK2PKT, and Bob in whatever he's doing.

RS> And THATS where you are having your brain fart, thats NOT what the
RS> SOT/EOT is primarily designed to be used, so the fact that its got
RS> some blemishes in THAT situation says nothing useful whatever about
RS> whether its useful for the original creator of the message.

FM> ... I know that's the original intention. My point is, IF
FM> (and I don't know) it is possible for a subsequent program
FM> to determine where to put those, then they aren't necessary.

RS> You havent established that thats actually true in the worst
RS> case where the message does not have a perfect end of message
RS> detail, and its also got some of that stuff embedded in the
RS> message body coz the user has inserted another message in the message
RS> body etc. Or something that looks like it like the --- line start.

RS> And you STILL havent established that even it it IS always possible
RS> to do it with an automated process, and it isnt, that it isnt a very
RS> considerable improvement to make it EASIER to work out where the
RS> message body is by bracketing it with the SOT/EOT pair.

FM> No, you did miss the point.

Nope.

FM> What I said was "IF... THEN...". I wasn't making a case one way or
FM> the other that it was possible, I didn't have the knowledge to do
FM> that then. But IF it were possible, THEN it wouldn't be necessary.

I KNOW that. *I* pointed out that it ISNT possible AND went on to point
out that EVEN IF IT WAS POSSIBLE, and its not, if the SOT/EOT allows what
is the user text MORE EASILY, your claim on 'necessary' is only true in
the legal sense, its still useful from the point of view of efficiency.

RS> In the simplest case where the SOT/EOT pair is in all messages, that
RS> saves all mail processing code having to fart around working out what
RS> the message body is by the more complex alg, even if its possible.

FM> We don't have that case, I don't see us *ever* having that case.

Irrelevant to your claim about necessary.

FM> And the algorithm ain't especially complex *anyway*.

Crap, its not even POSSIBLE with complete reliability.

FM> *Even* if it has to account for the fact
FM> that some messages have SOT/EOT and some don't.

Yes, the addition of the optional SOT/EOT doesnt change
much to the complexity of attempting to work our what
is user text when they arent certain to be present.

BUT, while the code needs to be there to work out what is user text
when there is no SOT/EOT, its VASTLY easier to work that out WHEN THEY
ARE THERE so you claim about 'isnt necessary' has imploded on TWO grounds.

RS> So your 'isnt necessary' has imploded.

FM> As I said, you missed the point. I was saying "IF... THEN...".

FM> Do I make it clearer in the above?

RS> You are still having a brain fart IMO.

FM> No, you missed the point.

Nope.

FM> And of course it maybe easier coming from QWK, if it doesn't have
FM> kludge lines anyway. But hang on, I get the opinion from your current
FM> discussion with Paul on this that it's not the ^a kludge lines which
FM> are the problem, it's the 'text' kludge lines (like ---) which are.
FM> And surely they're still a potential problem coming from QWK.

RS> Pity that if the SOT/EOT has some value with original creators of
RS> PKTs, your 'isnt necessary' has imploded tho. Its not about QWKs.

FM> I know that, it's about PKTs.

FM> SO. If it's possible for an automated process to do
FM> it, it ain't necessary. Except perhaps for efficiency.

RS> Pity that thats ONLY an automated QWK/PKT convertor Frank.

FM> Of course it is. Is it possible, in general,
FM> to scan a PKT and work out where to put SOT/EOT?

RS> No, not with imperfect messages. Consider the --- line for example.
RS> If the message doesnt have one, and there is one in the message body,
RS> you are fucked. And even if you add more rules on how far it is away
RS> from the origin line etc, its clearly still a lot simpler to just
RS> look for the EOT to determine where the end of the message body is.

FM> I see no point in looking for a ---.

It aint user text. If you want to work out what is user text, you need to.

Same applys with the kludge stuff too. If an reader is attempting to
not display kludge lines, it needs to be able to work out what actually
are kludge lines and what are things which would normally be kludge lines
in user text, but which arent kludge lines at all because they are between
an SOT/EOT pair and are in fact say a fragment of an included message etc.

FM> And, if you're writing a program which is going to
FM> correctly put EOT in the right place, it can correctly
FM> put the last, real, tear line in the right place too.

Pity that not all software which deals with EOTs deals with tearlines.
There isnt even any technical reason why you cant choose to have the
stuff like the tearline and origin line added ONLY when the message is
exported from the message base when its about to be sent to another system.

There are also systems which choose to retear existing messages. Etc etc etc.

FM> If you have an existing message created by some other
FM> software then you come right back to my original point...
FM> IF it's possible, THEN it's not necessary.

Still crap, because no only ISNT it necessary, even if it WAS necessary,
it may well be considerably more efficiently done with the SOT/EOT. That
may well considerably increase the rate at which you can toss messages
out of the message base into the PKTs for export to other system etc.

FM> And by the way, it's not possible, in general.

I TOLD you that. You are obviously just in silly buggers mode.

FM> If not why not, what stuffs you up from doing that?

RS> Its considerably more messy than looking for a EOT atleast.

FM> No, not really.

Yes really when you allow for less than immaculate messages.

FM> It's just not possible in some cases, and
FM> when it is possible it's very straightforward.

Nope, not when you allow for less than immaculate messages it aint.
@EOT:

---