Search the FAQ Archives

3 - A - B - C - D - E - F - G - H - I - J - K - L - M
N - O - P - Q - R - S - T - U - V - W - X - Y - Z
faqs.org - Internet FAQ Archives

Mailing list management software FAQ
Section - 2.00 What's your preferred software-design philosophy?

( Single Page )
[ Usenet FAQs | Web FAQs | Documents | RFC Index | Restaurant inspections ]


Top Document: Mailing list management software FAQ
Previous Document: 1.01 Using someone else's MLM
Next Document: 2.01 How much money, time, and expertise do you have?
See reader questions & answers on this topic! - Help others by sharing your knowledge
One of two philosophies is behind any program's design: "big is beautiful" or
"small is beautiful."  AT&T's original design for Unix was "small is
beautiful": small tools exist for every purpose, and they can be linked
together in defined ways to accomplish most goals.  On the other hand, Larry
Wall designed Perl, a program many people now think of as an essential Unix
tool, in the "big is beautiful" model: by combining features of sed, awk, C,
and the shell, he came up with something he and others believe is more than
the sum of its parts.

Why should you care?  Well, maybe you don't need to, but this "big vs. small"
dichotomy goes a long way toward describing the differences between the
available MLM's.  Look at the differences between Majordomo and LISTSERV as
examples of each approach, and see which appeals to you more.  (TULP is
probably an even better example than Majordomo, but I know Majordomo better
and will therefore use it for this discussion.)

When Brent Chapman originally wrote Majordomo, it was clearly a "small is
beautiful" program.  He had tried to compile and set up ListProc and gotten
frustrated; he whipped together something in Perl that would do what he
needed.  What he needed, specifically, was something to automatically manage
the addition and removal of subscriber names from his Sendmail alias lists.
As Majordomo was originally written, maintaining the alias lists was the
entire extent of its job -- *all* other work was handled by other programs.
Majordomo has expanded considerably since then (certainly beyond Brent's
original plans -- he has written that he thinks even the addition of file
server functions was a mistake, as they can be served as well or better by
dedicated archive servers), but the people working on it have tried to
maintain its purity of vision.  Majordomo tends to see most things in terms
of Unix regular expressions and Sendmail alias lists: for example, the
Majordomo equivalent of the LISTSERV "set digest" and "set nomail" commands
(which cause a user's mail to be batched, or not to be sent) is simple: to
stop getting mail, the user unsubscribes; to get digests, the user
unsubscribes, then resubscribes to a separate digest list.  This approach
obviously has limits -- LISTSERV offers dozens of options, for example, and
there can't be a list for each combination -- but that's OK, because
Majordomo doesn't want to provide every option, it wants to manage lists and
let other programs handle other jobs.  Because Majordomo is relatively small
and focused, it is comprehensible as a whole by many of the people who use
it.  This, along with its free source code, can explain much of its
popularity.

LISTSERV, on the other hand, is the MLM poster child for "big is beautiful"
programs.  As its users needed more features for various functions, Eric
Thomas added them to LISTSERV; his program attempts to satisfy every need a
mailing-list subscriber could have, and it does it in a fairly integrated
way.  However, LISTSERV and kin (primarily ListProc and Mailbase) are more
complex programs than the simple MLM's like Majordomo and TULP.

User Contributions:

Comment about this article, ask questions, or add new information about this topic:

CAPTCHA




Top Document: Mailing list management software FAQ
Previous Document: 1.01 Using someone else's MLM
Next Document: 2.01 How much money, time, and expertise do you have?

Single Page

[ Usenet FAQs | Web FAQs | Documents | RFC Index ]

Send corrections/additions to the FAQ Maintainer:
naleks@Library.UMMED.EDU





Last Update March 27 2014 @ 02:11 PM