
Here is my first draft of multiple back end support for Mailman.
There will be a Mailman front end and two back ends, one for the Config, and another for the Recipient List. The Mailman front end will start and read the mm_cfg.py file. This file will say which backends are used for the Config and Recipient List. This is the upper layer. The upper layer then imports the modules for the backend of the Config and the relevant Recipient List . For right now I am not messing with the admin approval que. I think maybe it should be tied into the Recipient List backend later.
Here are basic things I see Mailman needing to facilitate through
the backend of this API. Get the default config for lists on this site. Get the config for an individual list. Get a config item for an individual list. Add a recipient Remove a recipient Set a property of a recipient Set a property of a list Add a list Remove a list I believe that everything else can be handled by the frontend
The module for the Config will contain a class named Config with the
following methods: Config.GetConfig('List',) returns a dictionary of ConfigItem - ConfigItemValue pairs. List name '_Default_' will get the default config Config.GetConfigItem('List','ConfigItem') returns the ConfigItemValue Config.SetConfigItem('List','ConfigItem',Value) will set the value of an item for this
The module for the Recipient List will contain a class named List
with the following methods: List.SetRecepientProperty('RecepientName',Property,Value) will Set a property for a recipient. List.RemoveRecepient('RecepientName') will remove a recipient from the Recipient List. List.GetRecepient('RecepientName') returns a Dictionary of information on the recipient or -1 if there is no recipient by that name List.AddRecepient('RecepientName',Digest=Config.GetConfigItem('_Default_','Digest') etc. . ) this will add a recipient to the list with the default settings for the list except superseded by the caller List._init_() for creating a new list List._destroy() for removing a list
Here are some issues I am not sure I adderessed or understood. mixed and lower case mail addr.? logging? admin approval list should be in database ?
Each BackEndClass and Mailman version will have to have it's own version number with a set of methods / functions to upgrade from one to another.
I think it is best for the Config, Recipient list, and Recipient information objects to be dictionary's. That way if a later version of Mailman wants to add some feature or variable, it won't cause any problems with different sized lists etc. . . as long as we don't reuse key names. In addition each new version of the backend can check the marshal file, or database table or whatever and if it finds an older version, use an upgrade method or function to bring the old list up to date using the defaults for the site.
I apoligize for the crudness of this outline, and I am interested to see everyones suggestions. A. L.

Here are some issues I am not sure I adderessed or understood. mixed and lower case mail addr.?
technically speaking, the part to the right of the @ is case insensitive. the part to the left of the @ is considered case sensitive. That's how the RFCs define it.
In practice, nobody seems to worry about this any more, and is case insensitive across the entire email. What I do now is store the email as it's given to me, but do case-insensitive searches on it (so a user couldn't subscribe both "fred@aol.com and "Fred@aol.com" -- because in practice, while the RFC says they *can* be different people, no mailer with half a brain would try something that loonie any more...
admin approval list should be in database ?
I think the whole admin piece needs to be reworked. I've been mulling it over, but haven't written up my thoughts yet (being on vacation in Victoria eating, sleeping and relaxing has slowed my productivity a bit...)
-- Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com) Apple Mail List Gnome (mailto:chuq@apple.com)
And they sit at the bar and put bread in my jar and say 'Man, what are you doing here?'"

Hi,
On Mon, 31 Jul 2000 17:10:20 -0400, Andy Lowe said:
in the end maybe, but i guess there's no hurry with it... i think the held back messages should be kept on disk though
I apoligize for the crudness of this outline, and I am interested to see everyones suggestions.
well it look ok to me... at the moment i can't think of much to add to your outline... have you thought about how/where you want to do the development? i'd like to help out if necessary....
Ricardo.
"You think that's air you're breathing?" -- Morpheus

well it look ok to me... at the moment i can't think of much to add to your outline...
The big thing I can think of would be to add in backend support into pipermail. It would be neat to be able to store archives in a database.
<mode="wishful thinking">
Even neater would be to integrate UDMsearch (or similar) into the mix, so mailman became an all in one mail-list processor/archiver/indexer/search engine with a database backend. :)
</mode>
Darrell

Here are some issues I am not sure I adderessed or understood. mixed and lower case mail addr.?
technically speaking, the part to the right of the @ is case insensitive. the part to the left of the @ is considered case sensitive. That's how the RFCs define it.
In practice, nobody seems to worry about this any more, and is case insensitive across the entire email. What I do now is store the email as it's given to me, but do case-insensitive searches on it (so a user couldn't subscribe both "fred@aol.com and "Fred@aol.com" -- because in practice, while the RFC says they *can* be different people, no mailer with half a brain would try something that loonie any more...
admin approval list should be in database ?
I think the whole admin piece needs to be reworked. I've been mulling it over, but haven't written up my thoughts yet (being on vacation in Victoria eating, sleeping and relaxing has slowed my productivity a bit...)
-- Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com) Apple Mail List Gnome (mailto:chuq@apple.com)
And they sit at the bar and put bread in my jar and say 'Man, what are you doing here?'"

Hi,
On Mon, 31 Jul 2000 17:10:20 -0400, Andy Lowe said:
in the end maybe, but i guess there's no hurry with it... i think the held back messages should be kept on disk though
I apoligize for the crudness of this outline, and I am interested to see everyones suggestions.
well it look ok to me... at the moment i can't think of much to add to your outline... have you thought about how/where you want to do the development? i'd like to help out if necessary....
Ricardo.
"You think that's air you're breathing?" -- Morpheus

well it look ok to me... at the moment i can't think of much to add to your outline...
The big thing I can think of would be to add in backend support into pipermail. It would be neat to be able to store archives in a database.
<mode="wishful thinking">
Even neater would be to integrate UDMsearch (or similar) into the mix, so mailman became an all in one mail-list processor/archiver/indexer/search engine with a database backend. :)
</mode>
Darrell
participants (4)
-
Andy Lowe
-
Chuq Von Rospach
-
Darrell Fuhriman
-
Ricardo Kustner