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.