PE> Does anyone know what you are meant to call the outbound
 PE> packets?  I always get C7??????.PKT or something like that
 PE> from Dave.  BFN.

 dn> It is usually time/date based - you aren't "supposed" to 
 dn> use anything in particular other than generating a name 
 dn> which is likely to be unique for a reasonably long period 
 dn> of time simply to avoid collisions when adding packets to 
 dn> existing archives.

This is actually quite complicated.  If I don't use a file to store a
number, then if I have a small packet, which goes to 100 different people,
and gets processed in about 3 seconds on a 486, then I suppose I would have
"dummy" timestamps for the 99 filenames after the first.  Which
means if I run the mailprocessor again 20 seconds later, then there is a
chance it will have name clashes.  What does everyone else do about this? 
Ignore the possibility?

Anyway, destinations are certainly a lot more complex than reading it in. 
Too complicated to do properly without a design.  So I am going to write
some sort of design to isolate the processes from each other, so that I
don't force anyone to do something like use the timestamp when they want to
use a file.  Or force people to do entire mailprocessing when they only
want to see if they are arguing over mail, or only want personal mail.  I
have done this so far with lots of tests, which I think is a bad way of
designing it.  

Since working on a client-server application, I have come to realise the
beauty of client-server applications, and think that most functions should
be written with the idea that the user of the routine may be on another
system, and to not make rash assumptions (like a Zmodem protocol which
assumes that the output will be sent to a com port, and the input read from
a file).  BFN.

Paul

---