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 _______________________________________________ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers