[Freeipa-devel] Redesigning LDAP code

[Petr Viktorin]

On 01/11/2013 03:55 PM, Rob Crittenden wrote:
> John Dennis wrote:
>> On 01/11/2013 09:10 AM, Rob Crittenden wrote:
>>> Petr Viktorin wrote:
>>>> We had a small discussion off-list about how we want IPA's LDAP
>>>> handling
>>>> to look in the future.
>>>> To continue the discussion publicly I've summarized the results and
>>>> added some of my own ideas to a page.
>>>> John gets credit for the overview (the mistakes & WTFs are mine).
>>>>
>>>> The text is on http://freeipa.org/page/V3/LDAP_code, and echoed below.
>>>>
>>>>
>>>
>>> IIRC some of the the python-ldap code is used b/c ldap2 may require a
>>> configuration to be set up prior to working. That is one of the nice
>>> things about the IPAdmin interface, it is much easier to create
>>> connections to other hosts.
>>
>> Good point. But I don't believe that issue affects having a common API
>> or a single point where LDAP data flows through. It might mean having
>> more than one initialization method or subclassing.

Yes. I looked at the code again and saw the same thing. Fortunately, 
there's not too much that needs the api object: creating the connection, 
`get_ipa_config` which shouldn't really be at this level, 
CrudBackend-specific things, and `normalize_dn` (which I'd really like 
to remove but it's probably not worth the effort).


My working plan now is to have a ipaldap.LDAPBackend base class (please 
give me a better name), and subclass ldap2 & IPAdmin from that.
IPAdmin would just add the legacy API which we'll try to move away from; 
ldap2 would add the api-specific setup and CrudBackend bits (plus its 
own legacy methods).

So, the ticket shouldn't really be named "installer code should use 
ldap2" :)


> Right. We may need to decouple from api a bit. I haven't looked at this
> for a while but one of the problems is that api locks its values after
> finalization which can make things a bit inflexible. We use some nasty
> override code in some place but it isn't something I'd want to see
> spread further.

-- 
Petr³