On Wed, 2003-10-29 at 16:54, J C Lawrence wrote:
Aye, picking the right interface abstractions is key.
Right on.
There's also a disjoint between the novice SysAdm case who loves the fact of Mailman's all-in-one service, and the more meaty chap who integrates what he needs to. Much of Mailman's appeal at the low end is its all-in-one simple-to-install nature. (Well, ignoring thee GID FAQ...)
Yep, and I really really want Mailman 3 to take this concept farther. Some things that I think will help include, using Twisted to eliminate the /requirement/ of Apache integration and possibly the incoming mail server integration, as well as implement a bulk mailer to eliminate the need for an outgoing mail server. Ideally, it will still be possible to integrate with a Postfix for incoming and outgoing, but it shouldn't be necessary to get up and running.
Mailman v2.1 has a plugin layer for the membership roster. Its not a fully mature interface, but there are LDAP and SQL adaptors in the wild.
This interface was largely bolted on, so it's clumsy. Mailman 3 will be defined by interfaces from the start.
At some point those adaptors will move into the Mailman core. If we move the archiving components (storage, presentation, index) behind plugin interfaces as well there's a reasonable opportunity for similar third parties to build adaptor layers which then also move into the Mailman core.
Oh yeah, and just to keep Nigel Metheringham hopping:
Mailman just doesn't have enough configuration options.
Heh. That's another issue. I'm sure Mailman 3 will grow many more configuration options. The trick is making them manageable (and mostly ignorable -- i.e. the defaults Usually Work out of the box).
I've been experimenting with ideas for list styles which will make list admins lives easier I think, without reducing the flexibility for experts.
-Barry