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
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
Config.GetConfig('List',) returns a dictionary of ConfigItem -
ConfigItemValue pairs. List name '_Default_' will get the default
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
List.GetRecepient('RecepientName') returns a Dictionary of information
on the recipient or -1 if there is no recipient by that name
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.?
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