hamm@WAKS.RUTGERS.EDU ("Greg Hamm") (01/16/87)
I'd be interested to know how people archive useful network mail, especially for things as voluminous as INFO-VAX. Right now, I'm using a MAIL folder for each of several mailing lists, and just file the things away as I read them. Initially this seemed great; just file by subject, and then use SEARCH to find things. There are several problems with this approach: 1) There is no way to tie together related messages (e.g. queries and their responses); 2) One quickly accumulates hundreds of messages, which means that going for a cup of coffee is advisable after typing "SELECT VAX"; 3) SEARCH is of limited utility, since one can't search across different folders; 4) It's a horrible waste of disk space, especially given all the levels of mail headers; 5) The potentially very useful DIRECTORY display is rendered useless by some mailers in that the subject of all messages is something like "[TCP/IP Mail from <@LOCAL.DOMAIN.EDU,@SRI-KL:INFO-VAX...". I've seen others use EXTRACT and give the file a meaningful (usually long) name. This partially solves problems 2, 3, and 5, but seems to work well only if one is very consistent about naming schemes, which always seems to require more thought than an individual message is worth. [And then I'm continually SPAWNING from MAIL to see what I called other things.] Thinking about some better way to do this hurts my brain, and I've not yet found a solution with that "AHHHHH" quality to it. I'm sure some wizard out there must have. Basically, I'd like some scheme whereby messages are: 1) stored using data compression (as in a text library); 2) accessible to very flexible searching (like individual files); 3) have meaningful names (like files); 4) can be tied together in flexible and multiple ways (?); 5) easily directed to the scheme from MAIL, i.e. not via some hokey EXTRACT followed by remembering to execute a command procedure later. Anybody got any good ideas? If you prefer, respond to me directly, and I'll post a summary of solutions later. Thanks, Greg Hamm Molecular Biology Computing Lab Rutgers University hamm@biovax.bitnet hamm@waks.rutgers.edu ------
hamm@WAKS.RUTGERS.EDU.UUCP (01/18/87)
I'd be interested to know how people archive useful network mail, especially
for things as voluminous as INFO-VAX. Right now, I'm using a MAIL folder
for each of several mailing lists, and just file the things away as I read
them. Initially this seemed great; just file by subject, and then use
SEARCH to find things.
There are several problems with this approach:
1) There is no way to tie together related messages (e.g. queries and their
responses);
2) One quickly accumulates hundreds of messages, which means that going
for a cup of coffee is advisable after typing "SELECT VAX";
3) SEARCH is of limited utility, since one can't search across different
folders;
4) It's a horrible waste of disk space, especially given all the levels
of mail headers;
5) The potentially very useful DIRECTORY display is rendered useless by
some mailers in that the subject of all messages is something like
"[TCP/IP Mail from <@LOCAL.DOMAIN.EDU,@SRI-KL:INFO-VAX...".
I've seen others use EXTRACT and give the file a meaningful (usually long)
name. This partially solves problems 2, 3, and 5, but seems to work well
only if one is very consistent about naming schemes, which always seems
to require more thought than an individual message is worth. [And then
I'm continually SPAWNING from MAIL to see what I called other things.]
Thinking about some better way to do this hurts my brain, and I've not yet
found a solution with that "AHHHHH" quality to it. I'm sure some wizard out
there must have. Basically, I'd like some scheme whereby messages are:
1) stored using data compression (as in a text library);
2) accessible to very flexible searching (like individual files);
3) have meaningful names (like files);
4) can be tied together in flexible and multiple ways (?);
5) easily directed to the scheme from MAIL, i.e. not via some hokey EXTRACT
followed by remembering to execute a command procedure later.
Anybody got any good ideas? If you prefer, respond to me directly, and
I'll post a summary of solutions later.
Thanks,
Greg Hamm
Molecular Biology Computing Lab
Rutgers University
hamm@biovax.bitnet
hamm@waks.rutgers.edu
------