On Thu, 2003-04-24 at 21:19, Kevin McCann wrote:

1. External user database. I'm sure you're all aware of the desire of some folks to have this. I found a Wiki document somewhere on the zope.org site that had discussions on this but I believe it was somewhat dated. Have any conclusions been reached with respect to the direction here? I think I read talk of a Zope-specific solution. I'm wondering if this means that we're likely never to see a Mailman that can talk to a MySQL database. I believe this one feature alone would elevate Mailman significantly. How hgh of a priority is this to the development team and what is the status? Are there current discussions on this somewhere other than the list (wiki boards, chats, what-have-you) , and if so, may I take part?

This mailing list is the best place to discuss such things. Wiki gardening takes too much time. ;}

As Jeff Waugh mentions, Mailman 2.1 provides an interface through which it does all its user access, and a MailList extension mechanism you can use to substitute other MemberAdaptor implementations for the default legacy one.

While the 2.1 approach is a step in the right direction (I have an experimental BerkeleyDB-based backend checked into the cvs head), there are a few problems with it:

• It is a pretty inefficient interface for some tasks, most notably the admin membership management u/i. To build this u/i it has to load the entire user database into memory, even to display just a chunk of 30 addresses.

• The design is still list-centric. While I believe you could implement a backend that unifies the user database (e.g. barry@zope.com on list1 has the same user profile as barry@zope.com on list2), I want to make this much more evident in the interface designs. I want to invert the focus of Mailman from being list-centric to being user-centric.

2. Moderated-edit. I'm running Mailman on a couple of boxes but I also have a few hundred lists on a box running Lyris. I want to move them but one of the deal breakers at the moment is moderated-edit - the ability of a moderator to edit a message before it goes out. I personally don't use this feature for the lists I am the admin of but this seems to be a very important feature to some. An absolute must, in fact. I'm wonderig if this is in the cards, is it high on the priority list, should we expect to see it soon?

There is kludgey support for this now, that most people are probably not aware of: in the admindb interface, you forward the message to yourself. Then you use whatever tools you want to edit the message and resend it back to the list with the Approved header. Then you delete the message from the admindb. Not exactly the most efficient workflow. ;)

The thing that's always held me back here is designing a useable u/i to such a feature. Actually doing the editing probably isn't difficult, but I'm far from a web u/i expert. Doing it in a way that won't get clobbered by huge messages, be vulnerable to cross-site scripting or other security issues, and that provides a natural editing interface, is a big task. I wish there was some free tool we could just bolt on to do this -- I'm wondering if something like SquirrelMail could be appropriated for the task?

I understand this is a non-paying gig for Barry and others, and I understand there are likely a ton of other items to deal with. But knowing what the priority and status of these two items are would give me a realistic idea of when I might be able to drop the oh-so-commercial Lyris.

Hopefully the above gives some indication of the direction. I don't have much to say at the moment about ETA for any of this stuff, except that I'm beginning to experiment and write interfaces.

Finally, I'm not a Python programmer (yet), mostly Perl and PHP. But if I can help the cause in non-Python coding ways let me know.

I'm sure Python will be easy for you to pick up <wink>.

I wonder if we can start talking about how to get the community to take over more of the maintenance of the 2.1 branch so that I can start concentrating on the 3.0 work? Trying to do both in my spare time is difficult.

-Barry

<quote who="Barry Warsaw">

While the 2.1 approach is a step in the right direction (I have an experimental BerkeleyDB-based backend checked into the cvs head), there are a few problems with it:

• It is a pretty inefficient interface for some tasks, most notably the admin membership management u/i. To build this u/i it has to load the entire user database into memory, even to display just a chunk of 30 addresses.

I sort of suspected this when I first started hacking on it, but wanted to get my hands dirty before saying anything about it. Would you want backends to provide iterators? I guess it's a moot point considering what you say next:

• The design is still list-centric. While I believe you could implement a backend that unifies the user database (e.g. barry@zope.com on list1 has the same user profile as barry@zope.com on list2), I want to make this much more evident in the interface designs. I want to invert the focus of Mailman from being list-centric to being user-centric.

*yes!* :-) That would provide so many plusses both for users and the code. It would be a really good change, one I've been thinking about here and there whilst doing the LDAP backend. It would definitely make integration with different backends easier.

One thing I'm working on at the moment is list abstraction, so you can store all of the list information in different formats (I'm primarily interested in LDAP at the moment. With a few changes, there is the potential for dynamic membership too (ie. "the members of this list are found via this LDAP query").

I can't do all of this within the scope of my current contract, so if anyone's interested in LDAP integration, seriously scalable backends, or paying someone to help with the changes Barry describes above, please get in touch. :-)

I wonder if we can start talking about how to get the community to take over more of the maintenance of the 2.1 branch so that I can start concentrating on the 3.0 work? Trying to do both in my spare time is difficult.

That's possibly a good entry point for me, though I'm not too familiar with the rest of the codebase (beyond lists/members, backends, etc). I'm also pretty swamped with GNOME stuff too. But we'll see. :-)

Thanks,

• Jeff

-- linux.conf.au 2004: Adelaide, Australia http://lca2004.linux.org.au/

"When you're running, you want to run as far as you can, and you can't run further than Australia." - Jacek Koman