[Mailman-Developers] decoupling the web interface from the exploder.

[Darrell Fuhriman]

All right, I haven't done any Mailman hacking for a while, but I
wanted to work on adding this feature.

Let me explain why.

Right now, it's essentially impossible to have more than one
machine doing Mailman processing.  (Yes, there are ways to hack
around it, but they get ugly quickly.)

It's also impossible to have the web interface on any machine
other than the machine where list explosion happens.  This is
suboptimal, because you have the potential of having more than
one web server, or more than one mail box.

Let me give an example, from the real world, aka my setup.


                   |---------|
               /---|  MR/web |---\    |
 |----------| /    |---------|    \   |     |----------|
 | internet |<                     >--|-----|int. mail |
 |----------| \    |---------|    /   |     |----------|
               \---|  MR/web |---/    |
                   |---------|        ^
                                  Firewall


MR == Mail Relay.  All mail/web traffic is load balanced.

Now, I can't simply relay all traffic for mailing lists inside
the firewall, because then I would no longer have access to the
web interface.  Therefore I have to special case all my lists, to
have them exploded on the MR machine, then relayed to the
internal mail machine for delivery.

That part works fine for one machine, it doesn't work for 1+N.
Instead you have to do is have each of the N MR machines forward
all mailing-list traffic to one machine, and put redirects in
your web server to again point to that one machine.

That's kinda ugly, and defeats the purpose of having multiple
identical relays.

What I'd really like is a way to have the web interface be a
client which could get/set any mailing list configuration through
some sort of backend.  Then it would be trivial to just relay all
lists into the internal machine(s) for delivery.

So, if I understand it correctly there are three things that need
to be abstracted, and backends written (ideally, for me, to use a
database):

1) membership lists
2) list config
3) templates
4) archives


Now (1) seems to have been done already with MemberAdaptor, and
(2) shouldn't be that hard to do either, but will require
changing a number of the assumptions made in MailList.py and
probably elsewhere.

3) is annoying, but shouldn't be too hard to handle.  Again,
there just needs to be a defined interface.

The most challenging one is (4), which is easy enough to do for
the case of one delivery machine, but much harder for the 1+N
case.  It also needs to be abstracted.

So, I'll probably be able to devote time over the next couple
months to writing this, but I'm interested in how people feel
such a beast should look, especially (4).

Thoughts?

Darrell