[Mailman-Developers] Database API

[Andy Lowe]

I have found a way around my firewall, so cvs should not be an issue any
longer.

Jeremy Hylton wrote:
> 
> I am also interested in breaking up the way Mailman stores information
> about lists and subscribers.  I'd like the database API to be a bit
> more general, however.  There are a number of groups interested in
> using LDAP to store subscriber names.  Some people are interested in
> using Zope/ZODB, too, although I happen to think that mailing list
> subscriber data is embarassingly rectangular.

	I agree with you completely, and I attempted to do that.  I think a
LDAP backend to the currently proposed API would be fine, and as I said,
I am not very familiar with Zope, but as I understand it Zope is
basically a web site in a database.  This makes me think Zope would work
as well.  Do you have any suggestions as to how we could make the API
more general?  I am all for it.

> 
> I think the right approach is to write up a good architecture document
> that describes what data Mailman needs to store and what APIs can be
> used to plug in different storage technologies.  Let's get buy-in from
> people interested in RDBMS, ZODB, and LDAP before we start writing
> code.
	I theoretically agree with the above statement.  My problem is that my
boss says I have to have something which at least functions on our site
by the 9th of August :).  I think that may be a bit unrealistic, but I
am going to to my best to have something done by then.  I have tried to
write a rough architecture document, and I would love some help on it. 
I am inexperienced in this arena and would love to hear from those of
you who know more about mailman and can better describe what data
mailman needs and how the API should be set up.  As for ZODB and LDAP, I
am all for people interested in those backends giving input.  I have
failed to find anyone interest in helping with them yet.  Any takers?

> Once a good architecture document is in place and Barry releases 2.0
> final, we could probably convince him to allow major revisions to the
> CVS repository without branching.

Yet again I agree, but I am on a very tight schedule.  Perhaps I should
just hack something together for my sight while we wait for the final
release of 2.0  I am guessing that something like the backend API is
close to being worthy of a major version number, and would result in a
fork in the code anyways (where the 2.0 series continues to fix bugs
etc. . . until the first alpha in the next version is released)

	In the meantime I will rewrite / clean up the API architecture document
to solve approach the problem from the point of mailman data needs.
A.
 L.