[Mailman-Developers] Bindings, preferences, storage engines, oh my!

[Michael Chang]

The title says it all, no?

Folks,

I've peeked and poked around the mailing-list archives as well as the Zope 
Wiki, and I haven't yet seen anything that substantially fulfills what I'm 
looking for.  I've been using Mailman for a few years now, and as far as 
a mailing-list engine, it's great stuff.  However, when the time came for 
me to integrate it with other pieces of software, it left me high and dry.

The abbreviated version of what I need to do is this: write my own 
adminitrative front-end for global, per-list and per-user preferences; be 
able to store said preferences in an LDAP server.

I think it would be great to be able to access all of the preferences 
through any one of a number of common languages (Perl, C, C++, Java).  
That way, people could use the language that they feel most comfortable 
using.
As well, it would be a boon to be able to store and retrieve 
preference data in any format that one might choose (or choose to 
implement).

In order for both of the above to work, Mailman is going to need to access 
said preference data through plug-ins which sit atop a generic, "virtual
data preferences" layer which can access the preference data in an
administrator-defined way.  Upon installation, the administrator
will edit a configuration file that defines how the virtual preferences
will talk to the plug-ins -- essentially, the configuration file glues
the "virtual" to the "real."  The "real" can be anything from named
pipes to sockets to shared libraries to native Python classes.  Both
the Mailman engine itself and the out-of-the-box command-line utilities
that come with it will rely upon said glue file in order to access global-,
list-, and user-preference information.

 +--------------------------+
 |   preference modules*    |    (3)
 ---------------------------- ^
 [ configuration directives ] ^  (2)
 +--------------------------+ ^
 |  generic/virtual prefs   | ^  (1)
 +--------------------------+

1.) maintained by the Mailman developers

2.) a configuration file (possibly in XML format) that maps the
    generic methods (by name, I suppose) to preference modules.
	If the preference module is code, then just map the MemberAdaptor
	method names to get/set methods supported by the preference module.

3.) can be a socket, pipe, shared library, Python class, etc.  (Can Python
    bootstrap .so libs and call the functions within them?  Also, can
	Python talk to Perl scripts or Java bytecode?)


I think that once the above is taken care of, the storage method will
be a moot point, since there exist numerous libraries with numerous
language bindings for BerkeleyDB, various SQL servers, LDAP servers,
etc.

Putting the two together will allow people to be able to write their
own front-ends; additionally, it will relieve the Mailman developers
of having to develop and maintain any storage and retrieval code -- they'd
only have to take care of the virtual layer.  I suppose it would be like
Apache modules are to the Apache server, or how SNMP modules are to
the net-snmp suite where one can bind an OID to a shell script, a Perl
script, a C library, etc.

While I'd be willing to write my own preferences backend for the current
Mailman as it is, I'd be worried about the code changing from underneath
me within the next x release(s), thus forcing me to modify code just
to get things working again.

Any thoughts?  Has any work gone into this sort of thing yet?  Is there
any room in Mailman's plumbing to fit such a virtual preferences layer?


Michael



-- 
/* BEGIN SIG
 *
 * "Afraid of change, afraid of staying the same,
 *  when temptation calls, we just look away."
 *  - Barenaked Ladies
 *
 *-----------------------------
 * Michael Chang
 * miranda [at] uranus dot com
 * AIM: Solempathe
 * http://www.syndetic.org/
 */