On Thu, 2003-07-03 at 08:48, Kevin McCann wrote:
Barry, you mentioned that Mailman can work with MySQL, just not "out of the box." Can you expound on this? Or can anyone else? I'm about to do a lot of R&D in this area and would like to tap into what other people know so far.
Are we talking about data synching here, or is there a way to get Mailman to use MySQL to store its list config and membership data *instead* of these #&%^@! pickle files?
In MM2.1, all access to membership information is done through an interface, specified in MemberAdaptor.py. There's only one official implementation of this interface, the OldStyleMemberAdaptor.py that uses data attributes on the MailList object to store member information.
Now, the idea is that you could write a different adaptor, to store and access the information in any other database. I've written a proof-of-concept for storing the member data in a BerkeleyDB. You need to use the MailList extension mechanism to get the write adaptor implementation associated with the MailList, but that all works. That's what I meant by "not out of the box". I claim it isn't a lot of work to write a MySQL backend -- it certainly wasn't too hard to write a BerkeleyDB backend.
In MM3 (which I've begun to work on in my spare time), there will be several improvements in this regard. First, we won't tie the member database to MailList objects -- they'll be a layer of abstraction between them so we can fix the list-centric view of membership into a user-centric view (i.e. one login to rule them all :).
Second, there will be additional interfaces (actually, I intend to define interfaces for all pluggable components). For example, the list configuration data will be accessed through an interface so even it can be stored in a database. Also, I intend to define the member interface so that some operations can be more efficiently performed in the implementation, rather than in the application. E.g. when the admindb page alphabetizes and chunks the member listing, IWBNI the member database could do something more efficient than just returning a container with every list member, so admindb could throw away 90% of them.
FWIW, I have some working MM3 code, although I'm not checking stuff into the public cvs unti I have more of the directory layout and basic architecture working. It's just soooo much more convenient to have direct access to the CVS repository at this stage. I hope to have something reviewable soon, depending as always, on my available free time. If you want to drool though, I have working ZPT+Twisted web, backed by BerkeleyDB lists and member databases. It's raw and I can't send messages yet, but I think it's going to be really cool. :)
-Barry