[Freeipa-devel] Redesigning LDAP code

[Rob Crittenden]

John Dennis wrote:
> 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.
>
>

The reasoning IIRC was we didn't want a plugin developer mucking with a 
lot of this for their one plugin as it would affect the entire server.

rob