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/ */