Majordomo is a package for managing subscribe and unsubscribe requests for
multiple lists on a single machine. It is a nice little perl program,
and does what it does well, for which I'm very grateful, Brent.
The internet is exploding, and different listservers are being used by
many newbies. Listservers, therefore, should be simple and consistent.
1. adding functionality is, in general, a good thing. My version of
resend and majordomo have been hacked extensively. BUT my changes are mostly
internal (for the administrator), not external (i.e., the user interface
has not changed).
If Majordomo becomes easily extensible (add-in modules), will the user
interface become even more inconsistant from site to site? (I do want add-in
modules, mind you.)
2. talking about lists of servers and redistribution (LISTSERV-style
networks of servers): the problems here are ones of information
availability (how do I know what lists are available), distribution (how
to efficiently multi-cast mail lists), and centralization.
This is a topic with a much greater scope than Majordomo. I would argue
that bolting such functionality onto Majordomo would be counterproductive.
And the list-managers list or perhaps alt.internet.services might be a
better place to discuss it.
[something that just occurred to me is that you could set up a network
of gopher servers pointing into people's majordomo/lists directories,
with links to other servers or master lists of mailing list servers.
Don't reinvent the wheel if you don't have to.]
not to dampen anybody's enthusiasm, since I do think these topics are
interesting, but I'm just not sure that the Majordomo list is the place to
implement them.
john
troyer@cgl.ucsf.edu
Follow-Ups:
References:
|
|
