[Mailman-Developers] Mailman + DB

[Chris Ryan]

	A week or so ago I sent a mail, entitled 'Mailman + PostgeSQL'. Since I
have been doing my research on Mailman and getting an idea for how
things work in a big picture kind of way. From the many suggestions of
people who responded and of my own OOP background making the changes to
have Mailman access a data source in an abstracted manner would seem to
be the best solution. This email is directed to those who either develop
Mailman or have interest in the changes I'm proposing.

	My motives for making these changes are to allow Mailman to access data
from a database, PostgreSQL in my case. This is step one for me and my
development needs. With the desire to contribute said changes back to
the project in a meaningful way.

	With that in mind I'm suggesting the development of a standard data
containment method that would encapsulate the data. Then data source
containers can be developed and deployed for any storage method that
some could use such as PostgreSQL, ZopeDB, flat file, etc. I will be
working on this definition, hopefully with your input, and develop the
first instance using the current storage method. Once that has been done
and Mailman modified to use it then future data sources should be easy
to add.

	Outlining the basic encapsulation I will use names that are easy to
recognize but will not necessarily be the names used. The encapsulation
will actually be a collection of classes so as to make the flow easier
to maintain and understand.

---------
class List:
	# does the initialization
	__init__(self,listname):

	# these two are for compatibility of the current flat file method
	# and can be left to perform no action for those sources that don't
	# need them
	Load(self):
	Save(self):

	# one of each for each attribute
	# most of these will return the values that are expected
        # as Mailman is today
	get<Attribute>(self):
	set<Attribute>(self,value):

	# Members/DigestMembers will be handled a little differently
	# as to create a more uniform and clean interface as they
	# will return a Members class
	getMembers(self):

	# Other data will most likely be encapsulated as Members
	# such as postings_responses, request_responses and
	# admin_responses, bounce_info and any other attributes
	# that are 'complex'

class Members:
	# in my current thinking with the encapsulation it would
	# make sense to place both members and digest_members
	# within this one class providing methods to break out
	# each one as need.

	# each one of these would return the email keys (lc value of address)
	# the email key values hence forth will be referred to as userid
	# ??? why does Mailman care about case of the email addresses ???
	getMembers(self): # return a list of _all_ list members
	getRegularMembers(self): # return a list of all regular list members
	getDigestMembers(self): # return a list of all digest members

	# other methods of use
	getMemberAddress(self,userid): # return the case preserved email of
userid
	getMemberOption(self,userid,option): # returns 0,1 false,true
	setMemberOption(self,userid,option,state): # set/unset the option
	getMemberPassword(self,userid): # Returns the users password
	.
	.
	.
	# and so on

# there would be respective classes for the other 'complex' attributes
as stated above
# in List
-----------

	The classes with the definition and implementations would could be
defined under as such: Mailman/datasources/flatfile.py,
Mailman/datasources/postgresql.py and then using a config option the
respective file could be loaded with each of the classes into the
namespace allowing easy installation of new datasources for use. This
doesn't really handle the conversion from one source to another but
makes it easy for users to select the kind of source they would like to
use.

	I believe this to be a solid method for adding the functionality
desired. I would like to know if people think that this is a good idea
or not. Have I missed anything in my concept?

Chris Ryan
chris@greatbridge.com