[Mailman-Developers] Mailman and Extend.py

[Barry Warsaw]

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  
>>> 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.

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  
>> 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.

Yep.

> 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 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  
>> 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.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 304 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20090417/9d878fff/attachment.pgp>