Hi, Rod.

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

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

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

RS> RS> Its just as true if its got an internal editor too.

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

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

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

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

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

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

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

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

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

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.

We don't have that case, I don't see us *ever* having that case. And the
algorithm ain't especially complex *anyway*. *Even* if it has to account
for the fact that some messages have SOT/EOT and some don't.

RS> RS> So your 'isnt necessary' has imploded.

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

RS> FM> Do I make it clearer in the above?

RS> You are still having a brain fart IMO.

No, you missed the point.

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

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

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

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

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

RS> FM> Of course it is. Is it possible, in general,
RS> 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.

I see no point in looking for a ---. And, if you're writing a program
which is going to correctly put EOT in the right place, it can correctly
put the last, real, tear line in the right place too.

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

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

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

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

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

Regards, fIM.

 * * Support your local Police. Your life may depend on it!
@EOT:

---