TIP: Click on subject to list as thread! ANSI
echo: locsysop
to: Bob Lawrence
from: Frank Malcolm
date: 1996-06-09 04:26:12
subject: 4x16meg Simms 4 Sale

Hi, Bob.

BL>  FM> I can't work out whether you two just have a difference of
BL>  FM> opinion on the usefulness of SOT/EOT, or whether Bob (or even
BL>  FM> you) is missing some basic point in the other's argument.
BL>  FM> Perhaps when I come to study your reply it will become clear.

BL>   Paul is looking at it from the point of view of mail processing. I
BL> am looking at it from the point of view of a mail reader. In *his*
BL> case, he sees it as a foolproof way to isolate the text part of a
BL> message during processing... but why? In *my* case, SOT/EOT has no
BL> fucntion in a reader.

BL>   How I do it (for PKT) is:

BL> 1.  Read the null-terminated strings in the header.
BL> 2.  Read the first line (a) If AREA: then process area.
BL>                         (b) If not, process Netmail, address, etc.
BL> 3.  Strip all leading kludge lines (including SOT). Who cares?
BL> 4.  This leaves the message. Read message to null.

OK so far.

BL> 5.  Backtrack to find Origin line, read address. End of origin is end
BL>    of message.

Why the fuck are you back-tracking? Paul mentions this to, but perhaps
in a different context. And PKT2QWK, although I haven't actually figured
out if it's backtracking (it's in C, remember), is certainly processing
various bits of messages multiple times. Unnecessarily. No wonder it's
slow.

BL> 6.  Over-write fucking in-message kludges (EOT) with spaces.

Eh? Why? You just bin that/those line(s) on the way through.

BL> 7.  Display message with optional SEEN-BY line.

Yep, optional other kludges too if you want.

BL>   In a reader, SOT/EOT has absolutely no use at all, and in fact slows
BL> processing. It can't be used as a cross-check, because it most likely
BL> isn't there. If SOT is missing, with "AREA:" in the first line of a
BL> netmail message, all that happens is that the Netmail message is read
BL> under whatever area. So what? Who cares?

Or no area. Does your program, RIGHT NOW AS YOU'RE READING THIS, take
into account a pseudo-area line (as above) which either
  a) has some text which doesn't represent a valid area
  b) has a really really long piece of text which overflows something
  c) has not text whatsoever at all?

BL>   If the  * Origin line is missing, then I default to showing the
BL> entire message to the null terminator. So what?

I think that is correct. My conclusion, but waiting Paul's rebuttal, is
that EOT is neither necessary nor useful.

BL>   If the null is missing I'm rooted anyway.

Sure. But certainly your program should handle that gracefully, and not
run off into cloud cuckoo land from an accidentally grunged packet.

Regards, FIM.

 * * WARNING!  No user serviceable characters in this tagline.
@EOT:

---
* Origin: Pedants Inc. (3:711/934.24)
SEEN-BY: 711/934
@PATH: 711/934

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.