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

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

  The problem is that people quote other messages with the Origin line
intact. This gives you a message with two origin lines. The true one
is the one added by the softare at the end.

  In such a message you have to find the *last* origin line. The
way I do it is to find the end-null first, and go backwards to find: 
"#13 * Origin ", allowing that there may be a #10 following the #13
(or not).

  I don't bother with the Tearline in fact. I set the end of the
actual message at the end of the Origin line and show both on screen.
That way, I don't have to process the sen-bys. I just don't write them
to QWK. 

BTW, don't write SE*N-BY in a message. Most mailers including Paul's 
pkt2qwk will remove that line. ROFL! What a pack of arseholes!

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

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

  When I wrote that, I hadn't found Move() in Pascal. I assume by "bin
those lines" you mean move the following section of the buffer along
to overwrite those lines one at a time. I prefer to ignore the control
lines rather than overwrite them. That's why EOT gives me the shits.
It's the only one I have to overwrite.

 BL> 7. Display message with optional sen-by line.

 FM> Yep, optional other kludges too if you want.

  No... I don't bother. The classic reader processes all kludge  lines
at once. I don't. They get a bit wearing in every message. The ones at
the bottom are tolerable.

 BL> If SOT is missing, with "AREA:" in the first line of a netmail
 BL> message, all that happens is that the Netmail message is read
 BL> under whatever area. So what? Who cares?

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

  If I find an invalid area (identified by "AREA: in the first line),
I put it in an area called UNKNOWN and read it anyway. Such a message
would not get through Paul's mailer, but it's useful for me if Areafix
gets a new area and I forget to put it on the list.

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

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

  My approach is to save *all* mail. The first thing I do with mail is
to save the raw packets, so that even if a packet is rooted I can save
it fix it and read it. Fifo is more anarchic. Bad mail is dumped and
up your arse. It seems to work.

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

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

  I runs into cloud cuckoo land but saves and names the packet for
repair. The problem is identification.

  The only fixed PKT field is date/time, so a missing message null
could be identified by that and terminated 14 bytes in front of the
following pair of nulls spaced 20 bytes... but *every* message would
have to be checked that way. I didn't bother.

  Such a message can't get through the mailer anyway. If I were
writing a mailer I'd be worth it, but then you'd have to check
sender names as well, in case you combined two half-messages.

Regards,
Bob



     

  
___ Blue Wave/QWK v2.12
@EOT:

---