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):
- membership lists
- list config
- templates
- 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.
- 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