BL> The problem with file attach is that someone else pays the
 BL> bill. With a letter-drop, only the users pay.

 PE> file-attach is a problem for me to solve in Tobruk. I don't
 PE> currently support that under OS/2, so nothing will change going
 PE> to Linux. 

  I still think the TIC letter-drop approach is more ethical... if we
could only speed it up a bit.

  How do you like the idea of sending a TIC with no file to erase the
file (if it's on the disc)? THEN, a person picking up a file just for
them would FREQ the file and TIC it too, and delete it after they got
it. It seems foolproof to me. If I sent the TIC and lost the file,
then it must mean that I intended to overwrite the file anyway, so why
not erase it? If I sent the file and lost the TIC, then nothing would
happen except the file would not get past the inbound. 

  How do you like the idea of a use-by date and automatic erasing? It
would be easy enough to check the description for a date and remove
the file once it went over. That would save sending another TIC and a
zero-length file to delete it.

  How do you like the idea of including the sender's intials at the 
head of the description (or the end)? At present, yatic adds [00] for 
a reason that makes no sense to anyone but a psycho-potato. 

 BL> 1. Look in inbound for POST/files, check for files and
 BL> password.

 PE> I don't see why you can't call it .TIC instead of POST.

  I don' want all the TIC baggage so I'm keeping my options open... but 
I'm trying to keep it compatible anyway.

 BL> 4. Sort specialr list, update FILES list.

 PE> As I said, I think you should separate this out into a separate
 PE> utility. 

  At present, I'm loooking at doing it in two parts: a quick update to
include the new file with no directory check (because it's just put it
there anyway), and then the later, more thorough rebuild. It's turning
out quite fast, actually.

 PE> All packets need a packet header. If you require that I supply
 PE> my own, and prepend that, and post-append a couple of NULs,
 PE> then that can be done too, although obviously with more hassle!

  I wasn't sure how the system worked inhouse. I thought perhaps you
had another way to keep track of messages. No worries...

 PE> TIC only gets run (currently) after the caller has hung up.

  That's a real bummer! A failing of TIC is that it's one-way. You
never know if it worked until you get the new FILES list the next
day. It's still a good system, but you only have to see the messages
to see where it fails: "I forgot to send the TIC; I forgot to send the
file; what happened to the file?"  Oh, well. Life sucks.

 PE> If you call it temp.pkt, that is fine, I can get tobruk to toss
 PE> it, and tobruk will create a new pkt, call it 00044629.pkt
 PE> (etc) and then squish will compress it into an outbound
 PE> archive. Alternatively you could create the 00044629.pkt file
 PE> yourself. I suggest you use the number of seconds since 1970 to
 PE> name the .pkt.

  Okay. GMT 1-1-70... my worry was that TIC might create a whole set
of tmp.pkt files if someone sent a whole lot of bad ones.

Regards,
Bob
 


  
___ Blue Wave/QWK v2.12
@EOT:

---