[Freeipa-devel] Redesigning LDAP code

[John Dennis]

On 01/11/2013 09:55 AM, 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.
>>
>>
>
> 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.

Ah, object locking, yes I've been bitten by that too. I'm not sure I 
recall having problems with locked ldap objects but I've certainly have 
been frustrated with trying to modify other objects which were locked at 
api creation time.

I wonder if the object locking Jason introduced at the early stages of 
our development is an example of a good idea that's not wonderful in 
practice. You either have to find the exact moment where an object gets 
created and update it then which is sometimes awkward or worse 
impossible or you have to resort to overriding it with the setattr() big 
hammer. Judging by our use of setattr it's obvious there are numerous 
places we need to modify a locked object.

It's not clear to me if the issues with modifying a locked object are 
indicative of problems with the locking concept or bad code structure 
which forces us to violate the locking concept.


-- 
John Dennis <jdennis at redhat.com>

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/