Barry,
You are right about Python. Fun and not too tough to learn.
What kind of help are you looking for? I've been programming for a while...I started on a Trash 80 back in the day. Mostly been doing 'web/db stuff the past few years.
I've started playing around with some of the admindb stuff, working on getting the interface to look a bit more purdy. I was planning to poke around and see if I could set up a way to allow an admin to more easily add a logo to all pages, etc.
Brian
At 04:58 PM 5/1/2003 -0400, Barry Warsaw wrote:
On Thu, 2003-04-24 at 21:19, Kevin McCann wrote:
- 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.
- 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
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers
Thanks,
The admin staff admin@chirolists.com