On Apr 16, 2009, at 5:05 PM, C Nulk wrote:
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?
Well, not exactly. It should be possible to get the same functionality, but it will have to be done differently. For example, the *_these_nonmember attributes are gone.
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 configureMM3 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. Ifyou 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.
You don't really need to know much about Zope to understand zope.interfaces. Really, just think of these as a formal way to specify interfaces to components. The package originated in the Zope world which is why it lives in the 'zope' namespace.
Integrating different RDBMS should be pretty trivial. If Storm supportsit, 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.
Yep.
I did take a quick look at it but I sufferfrom several handicaps - main one being I know extremely little Python.Just ask Mark Sapiro about that :):).
;)
I also looked to see if there wasan URL type interface for LDAP. There is however it would be primary bean anonymous bind to a LDAP service. Most if not all places will notallow 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 canbe 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 don't think LDAP is a good fit for Storm, which really wants to be talking to a relational database via SQL. The bad news is that using Storm is the easy way to hook MM3 up to a different backend. The good news is that (hopefully) that's not necessary to use LDAP for your user data. I think you would need to re-implement things like the UserManager, but this is mostly uncharted waters.
I'd be happy to help anybody who's interesting in building out an LDAPbackend.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 anLDAP query will always return every entry matching the query, someonethat wishes to unsubscribe cannot because their entry is included in thequery. If whatever mechanism is used to track a given list member'sconfig settings (mod, ack, nomail, etc) also includes whether the personunsubscribed 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.
I think I see what you're saying. You really want to split user data across LDAP and say a relational database. While I think it could be done (and probably /should/ be doable), it will take some clever model- layer programming to make it work. I don't have a clear picture in my mind about how to do that right now, but it's worth an interested developer to take a look at it.
-Barry
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
