Hello Barry,
Thank you for responding. A quick question, will MM3 also support the @list funtionality, both for the 4 *_these_nonmembers options and the owner, moderator, and the ban_list options?
Barry Warsaw wrote:
On Apr 14, 2009, at 5:28 PM, C Nulk wrote:
I figured as much. And thank you for answering my next question about Mailman 3. Is there documentation somewhere I can read how to configure MM3 for using LDAP or any other back-end database?
Yes and no. There are lots of doctests in the MM3 code, which primarily serve as documentation. Navigating around to find the information you want may take some time as there's no overview. There are currently no doctests describing how to use different backends, but the basic idea is that MM3 is strongly component based, using Zope style interfaces. If you can provide different implementations of the backends for core objects (mostly in the mailman/database package), then the rest of Mailman will just work.
While I have heard about Zope, I am not familiar with it.
Integrating different RDBMS should be pretty trivial. If Storm supports it, then it's just changing a URL in a config file. For an LDAP backend, it will take some additional implementation work to write different implementations of IMailingList and such that don't do SQL queries to gather the necessary information.
I am also not familiar with Storm. I am guessing it is the Storm from http://storm.canonical.com. I did take a quick look at it but I suffer from several handicaps - main one being I know extremely little Python. Just ask Mark Sapiro about that :):). I also looked to see if there was an URL type interface for LDAP. There is however it would be primary be an anonymous bind to a LDAP service. Most if not all places will not allow anonymous binds which can update/change their LDAP information. I just don't know enough about Storm to say whether or not the DN bind can be worked in.
The current LDAPMembership.py get the LDAP data. It might be possible to use the ideas there to implement LDAP in Storm.
I'd be happy to help anybody who's interesting in building out an LDAP backend.
My poor knowledge of Python most likely leaves me out with respect to developing, however, I would be happy to be involved in contributing ideas towards the development.
One idea I did have is about keeping unsubscribe information. Since an LDAP query will always return every entry matching the query, someone that wishes to unsubscribe cannot because their entry is included in the query. If whatever mechanism is used to track a given list member's config settings (mod, ack, nomail, etc) also includes whether the person unsubscribed or not, then whenever the getMembers()/isMember() or equivalent functions are called, the query results minus the unsubscribed is checked/validated/etc. depending on the function.
Sorry if the above sounds like gibberish. Could really figure out how to say it better.
Thanks again,
Chris