DRAFT Datasource Interface v0.1
All,
I've written up a templatish python code of the inteface with some
comments and the like. I've placed everything on the Mailman ZWiki page http://www.zope.org/Members/bwarsaw/MailmanDesignNotes/CentralizedUserDataba... at Ricardo's sugestion so that you may all read it over and comment/add/substract ?delete? :).
There were a few places that I left empty in the interface but I
commented about it these were The Admin/Request/Postings Response classes and the bounce_info stuff which will be located in the BounceData class. This was due to my lack of overall understanding of what these are at this time. Feel Free to fill them in following the overall flow of the rest.
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.
Chris Ryan chris@greatbridge.com
Thanks Chris. My workload's a bit backed up now that IPC9 is over, so I'm not sure when I'll get a chance to review this. I'll try to take a look some time this weekend.
-Barry
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/CentralizedUserDataba... 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.
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.
Anyway, I also wanted to comment a bit on the draft you wrote: like getting a list of subscribers and digest subscribers, or both. Is there
- I see you created seperate functions for a lot of related things,
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. peformance reasons to be able to use sql queries in the backend so maybe that's
- 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
something we should keep in mind when defining the functions.
-- Regards,
Ricardo
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/CentralizedUserDataba... 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: like getting a list of subscribers and digest subscribers, or both. Is there
- I see you created seperate functions for a lot of related things,
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
participants (3)
-
barry@digicool.com
-
Chris Ryan
-
Ricardo Kustner