Barry Warsaw wrote:
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.
As I walked to the train station last night, I came to the same conclusion. Since LDAP is not relational, Storm would need to make exceptions for LDAP. Definitely not a good fit.
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
Well, not really splitting up the data between LDAP and a relational DB because you will end up with sync problems at some point in time. It was more of adding/modifing text attribute values in LDAP. I will explain it more fully next week when I start a new thread (I just saw your responses and I need to close up and head for the train).
Chris