>>>>> "BC" == Brent Chapman <Brent@GreatCircle.COM> writes:
BC> For example, Majordomo might look for module files in a particular
BC> directory, which would contain code that would then be incorporated
BC> into Majordomo.
My problem is one more of coding than of understand the basic concept. I'm
just not sure how to best implement it.
One idea that comes to mind is to have a modules directory; every file in
that directory is require'd. These files would define the necessary
subroutines and add entries to certain global hashes which control command
processing. Hmmm.
BC> There are times when the best thing to do with a function is throw it
BC> out and write it from scratch...
Yeah, but because the development base is so small I'm inclined to do it a
piece at a time if possible. This at least gets a new release out every
once in a while.
>> Goals for 2.x (in no order): Perl5 only. Address list kept in database
>> (x > 0).
BC> Gotta be optional.
Oh, of course. Everything should be optional. But the functionality is
absolutely required for running active lists with >10000 members.
Also, Dave pointed out that I've implicitly added another level of version
number here; that's not what I intended to so. I was merely trying to
order these goals in the way that I would do them, were I working in a
vacuum.
BC> As I've posted elsewhere, I'd be tempted to do WWW first if I was
BC> starting from scratch, and maybe not even bother to do an email
BC> interface to list management functions (i.e., only handle routine user
BC> stuff via email).
Yeah, but too many people are already running it that way, and there are
quite a few lists that are run by someone using Groupwise or something on
an internal network who doesn't have net access.
BC> If there's a WWW interface, I don't think these others are necessary.
I think that a command line interface should be in there. If it's nearly
free to code, why not? (Accept arguments, call one function, return
status.) Doing it via email is too much (and you don't get immediate
feedback), and running a web browser, authenticating, and clicking all over
the place just to unsubscribe an address is way too much, especially if
your browser is Netscape.
I recognize that the command line interface doesn't work unless you're on
the server. Unless, that is, you're doing the client/server thing, in
which case you just connect over the net.
>> Build resend functionality into the server. Mails are accepted by a
>> tiny, possibly even C program that just contacts the server and sends
>> the message over a socket to be delivered. Since we may not have
>> addresses in a flat file, we'll have to talk SMTP ourselves.
>> Incorporate some or all of TLB functionality.
BC> This I have strong reservations about.
BC> First, let's avoid C. I'd like to get rid of wrapper.c altogether; I'd
BC> like to have never needed it in the first place, but it was necessary
BC> because of bugs related to setuid code in the versions of perl that
BC> were in common use when Majordomo was first written. Let's keep
BC> everything in one language.
I propose this because you don't want to incur Perl invocation overhead if
you can help it. A little perl thingy to do this (send the incoming mail
through a socket to the server) is trivial, but if you're carrying
thousands of messages per day the overhead of compiling the script and such
are going to be killers. B (the perl compiler) may change this; I don't
know. I can't see why using a little C program isn't a viable alternative
if it's not required and the performance gain is measurable.
BC> Second, queue management is hard. That's why I left it to Sendmail,
BC> both incoming and outgoing. We may not be able to avoid it forever,
BC> but I'd like to avoid it for as long as possible.
I'm not proposing doing any kind of queue management.
BC> Third, what do you mean by "talk SMTP ourselves"? If you mean "talk
BC> SMTP to the local mailer in order to queue the outgoing message",
BC> that's fine.
Yes, sort of. The problem is that if you have the addresses in a database
you can't just use an :include: line in /etc/aliases. You have to pass the
addresses in a bunch of RCPT TO:s, so you need to know how to talk SMTP.
Fortunately I've already written a bunch of code to do that. Enter:
BC> Fourth, what is TLB? :-)
Not paying attention, I see. ^_^ It's a tool that I've been developing
that does what bulk_mailer does (split the list into a bunch of small SMTP
transactions), but is more configurable and has the ability to deliver
using multiple hosts in parallel. I announced a couple of versions in
majordomo-workers. I started working on it because there was some talk of
building bulk_mailer-like functionality into resend, but I gave up on doing
in a perl4 compatible way. To do a delivery, it:
Splits the address into classes (by regexp match).
Sorts the classes by reversed domain (optionally).
Takes each class and splits it up into batches of various sizes and
properties.
Takes these batches and evenly distributes them among a list of hosts that
will deliver that class of addresses.
You can do things like use a host in Australia to deliver for all of the
addresses in Australia and New Zealand. Or spread the delivery load over
several outbound mail hosts. It will also send the message to external
programs like archive2 and digest; together with the use of $mailer in
majordomo.cf you can do your deliveries with TLB and have no outgoing
aliases at all. It also comes with a tool to strip comments from and sort
by reversed domain a list of addresses.
I gave out a couple of public releases, but TLB is complicated and is still
a little rough on the documentation end so I stopped doing public
releases. I do use it to deliver all of my lists. If there is still
interest I'd probably be able to whip up a release in short order. It does
much more now, like proper syslogging of performance data and
warnings/errors.
- J<
References:
|
|
