[Mailman-Developers] DRAFT Datasource Interface v0.1

[Chris Ryan]

Comments within:

Ricardo Kustner wrote:
> 
> Hi,
> 
> First of all, a disclaimer :) I'm not a core mailman developer but
> I'm interested in helping out with this and I (think I) know a bit about the
> internal workings as I've been following mailman development for a while now...
> 
> On Tue, Mar 13, 2001 at 01:33:50PM -0500, Chris Ryan wrote:
> > http://www.zope.org/Members/bwarsaw/MailmanDesignNotes/CentralizedUserDatabase
> > at Ricardo's sugestion so that you may all read it over and
> > comment/add/substract ?delete? :).
> 
> Looks great ! I'd also suggest using ZWiki's feature to create subpages and/or
> subsections on the same page; If we get one long page with information
> it could get a bit hard to follow. For example you could divide it into
> the phases you wrote about earlier.
>

	I'm just now starting to use the ZWiki source so I must apologize for
the lack of organizational zest. I will play around with it some later
and see about breaking it up.
 
> >       Once we get something that is more or less acceptable my next step will
> > be to impliment the interface to use the existing method of data
> > storage. Then I would start modifying the code to use the interface.
> > Once I've got the interface implimented we should have a concreate
> > definition and anyone should be able to write a datasource driver using
> > the interface to access what ever source they wish to use.
> That's were I definately want to step in... I could work on a mysql driver.
>

	This would be great. I will be working on PostgreSQL myself. Perhaps
the two of us could design a table structure that will work for both
PostgreSQL and MySQL allowing users to switch easier between the two.
 
> Anyway, I also wanted to comment a bit on the draft you wrote:
> - I see you created seperate functions for a lot of related things,
> like getting a list of subscribers and digest subscribers, or both. Is there
> a specific reason for that? To me it looks like it might generate some
> duplicated code... what are you thoughts on how to handle code re-use?
> same goes for getting the flags for a member. Maybe it's something you
> already thought about, but I just wanted to point it out just to be sure.

	Let me start by saying that originally I had several member function
for each option before I consolidated them into overloaded methods. I
know there are a few that I missed or for a lack of understanding chose
to ignore. For instances such as listMembers(), listNormalMembers() and
listDigestMembers() I was trying to provide simple methods to accessing
the data. As for the member flag methods I chose to do those as separate
methods to allow flexibility (for the driver developer) and ease of use
(to the interface user). I am open to any suggestions that simplify the
overall interface and still allows Mailman to perform it's functions.

	To Specifically address the code reuse aspect. My goal in this design
is to provide a clean interface for mailman to use. It would be up to
the developer to implement this interface in the most code efficient
manner.


> - At some points mailman might need to find a specific list of
> subscribers... though it's possible to load the entire list into memory
> with listMembers() and work on that with python code, I think it would be nice for
> peformance reasons to be able to use sql queries in the backend so maybe that's
> something we should keep in mind when defining the functions.

	The only problem with this is it is possible that not all
implementations will store data in the same manner which makes it
difficult to add in such methods. That is why I tried to define all the
methods so that they each perform specific tasks with specific results.
Probably the best thing to do in a situation like this is to determine
the specific need of Mailman then add a method into the interface that
performs the desired task.

Example:
	Task: find all users on a list that are in a domain
	Result: a list of users by key that match a domain
	Definition: MemberData.listMemebersInDomain(domain)

	It would be up to the Interface driver developer to determine how this
gets done. I am not opposed to adding such methods if they are used,
especially to speed up performance.	



Chris Ryan
chris@greatbridge.com