| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| 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™.