[Mailman-Developers] MySQL Support? Do tell!

[Barry Warsaw]

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