[Freeipa-devel] Redesigning LDAP code

[Jan Cholasta]

On 11.1.2013 16:20, Petr Viktorin wrote:
> 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).

I would prefer if ldap2 was the base class, but I guess that's just an 
implementation detail. "ipaldap.LDAPClient" sounds better?

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

Honza

-- 
Jan Cholasta