>>>>> "LM" == Leslie Mikesell <les@Mcs.Net> writes:
LM> I don't see any reason to combine the list handler and the archive
LM> handler in the same program at all.
In order to extract the messages to build the digests. (Well, sort of,
that's the reason the digestifier depends on the archiver; the list handler
doesn't really depend on either.) Plus there's the issue of message and
header modifications that you want to go to the list but you don't want in
the archive.
The point is not to have one huge monolith, but to have a bunch of
cooperating modules instead of a bunch of cooperating programs. It's sets
of routines and APIs now instead of executables and command line options.
The modules aren't even touched (i.e. not brought into memory) if archiving
and digestifying aren't turned on. You can use the modules separately; you
could have a front end that just uses the archive module and works just
like archive2.pl. You'll note that it's even on the TODO list.
LM> Why not make a generic email to archive program, connect it to a
LM> separate alias and subscribe the alias to the list?
message_fronter, message_footer, subject_prefix, MIME filtering (strip GIFs
from the delivered copy but leave them in the archive), etc. But if you
want that, feel free to work on the front end I mentioned, or wait until I
get around to it.
- J<
References:
|
|
