[turba] turba ldap driver

[Ben Sommer]

Hi All. My question is in reference to ldap configuration in turba. 
Chuck asked me to post my question for ldap-experienced folks to comment on:

Problem: the schema for my LDAP addressbook does not match the 
assumptions built into turba. The man previously in my position hacked 
turba 1.2 to make it work with the schema. I'd like to now address the 
shortcoming in turba directly.

Our addressbook schema uses an object class called 'uniqueEntryObject', 
describing objects with a "Unique Entry ID" (ueid) as RDN naming 
attribute. The reason should be obvious - a long list of peer LDAP 
entries (i.e. entries sharing a common immediate parent) such as an 
addressbook can't have clashing RDNs, something that would inevitably 
happen with turba, since the default configuration seems to simply use 
the 'cn' attribute (or some other user-defined attribute) as the RDN.

Also, my confusion about whether turba could be configured to work with 
this schema was compounded by the param 'dn', which is misnamed. It 
should be 'rdn', and its value should not be an array - since an RDN is 
by definition _one_ attribute. All the code in lib/Driver/ldap.php that 
munges this array (i.e. _makeKey, _save) should be refactored 
accordingly. I can do this, but I want to sound it out to you all first.

Second, the capability to make the RDN attribute non-user defined should 
be added to the driver and the config/sources.php examples. Reasoning is 
the same here too - the RDN must be unique, and therefore 
system-generated - just like an auto-incremented ID in an SQL database. 
We kinda have the right idea in lib/Driver.php with '__uid', but this 
should be configurable from within an LDAP turba data source. (The use 
of the name 'uid' here was another confuser!)

That's all. What do you think?

-- 
Ben Sommer
Senior Technology Officer
Eastern Nazarene College
23 East Elm Ave
Quincy, MA 02170
(617) 745-3817