>>>>> "JB" == Jorge Biquez <jbiquez@icsmx.com> writes:
JB> What would be the best resource to study about this?
There's a paper presented at a LISA conference written by Brent Chapman
that talks about why the wrote Majordomo and what problem they were trying
to solve. If you understand what they were originally trying to do, you
will have some deep insight into why Majordomo1 works the way it does.
Some quick notes:
First they just wanted automatic maintenance of an address list that
Sendmail would expand.
Later, they added filtering (i.e. resend), then the moderation and post
approval mechanism.
After that, they put in the remote configuration system, so you could
actually manage a list remotely
Some time in there they also added simple file distribution.
That brings you up to 1.92, I think. Maybe 1.90. I don't remember what
was in 1.68. I've never been near the source of anything older.
Everything from 1.92 to 1.94.x has been tweaks. I came in at 1.93 but
didn't start contributing until my rewrite of the approval stuff in 1.94.1
(I think). This is around '97. (Some will remember the marathon hacking
session that got the code done before I went on vacation.)
I started tinkering at 1.94.1, at which point I branched a private 1.95
that nobody ever saw. I started rewriting the command parser (because it
was nasty) and wanted to add MIME handling to it. But MIME-Tools was perl5
only, so I started removing perl4-isms.
Eventually I came down to just a few design decisions:
1) Addresses needed to be stored in a database, so additional data could be
tracked with them.
2) All core functions should pass through a single access control
mechanism. This needed to allow any command to be stopped pending some
kind of approval. The access control mechanism needed to be extremely
flexible.
3) The core set of functionality should be split from the interface and
stuck in a library.
The user requests that drove these were:
1) Need to be able to set nomail/vacation status. Digests need to be a
setting on the main list, not a separate list. Need to let a user not
get copies of their own posts.
2) Lots of people asked for various different restrictions or exceptions.
I.e. "ban some posters", "force approval for subscriptions from AOL",
something less restrictive than "only members can post" that doesn't get
a moderator involved. Plus I have a belief that postings should never
be rejected without a human at least reading them, but lots of others
don't agree.
3) Majorcool is neat, but the way it works internally is horrendous. It
should be able to just call the Majordomo library to do stuff. Plus, I
wanted a command line interface.
There were other "minor" requirements that shaped the code: Multiple
digests per list and on-demand custom digest generation (which drove the
integration of the archive system and the building of digests from the
archives). Automatic MTA configuration and support for multiple MTAs.
Flexible delivery to help sendmail go faster (which, along with the
"addresses in databases" stuff, required that we talk SMTP directly to the
MTA. Automatic bounce handling.
Now, once those main three design decisions were arrived at, I decided
there was only one thing to do: delete all of the code and start over.
This also enabled a license change, to something which is actually
considered a "free software" license.
Anyway, that gets us to '98. The rest is just me working away, essentially
alone, until SRE came in and started writing documentation. Then Michael
came along almost precisely when I burned out completely after three years
of sinking all of my free time into the thing. He revived the whole
project, and more recently I've been getting back into to contributing a
bunch of code.
I hope this helps you.
- J<
References:
|
|
