[Freeipa-devel] Fwd: Type conversions (was: enhancement tickets)

[John Dennis]

Forwarding to freeipa-devel where this should have gone in the first 
place ...

-------- Original Message --------
Subject: Type conversions (was: enhancement tickets)
Date: Mon, 09 Jan 2012 09:44:49 -0500
From: John Dennis <jdennis at redhat.com>
To: Jan Cholasta <jcholast at redhat.com>
CC: Rob Crittenden <rcritten at redhat.com>,  Martin Kosek 
<mkosek at redhat.com>, Endi Sukma Dewata <edewata at redhat.com>,  Petr 
Vobornik <pvoborni at redhat.com>, Alexander Bokovoy <abokovoy at redhat.com>

On 01/09/2012 03:34 AM, Jan Cholasta wrote:

>>> And ticket 2033. I have a vague notion you decided to defer this, am I
>>> remembering correctly?
>>
>> Nope, I'm working on a patch to fix this ticket. I had a patch for it,
>> but I have realized that the problem lies deeper than I thought, so I'm
>> working on a new patch now.
>>
>> The new patch changes the way parameter values are encoded and decoded
>> so that it is done in "border" backends (ldap2, xmlclient,
>> Executioner-based backends) instead of doing it ad-hoc all over the
>> code. This means that when a value enters IPA (either from a RPC
>> interface or from LDAP), it is converted from the backend-specific type
>> to the parameter type (which can be anything now, IP address object, DN
>> object, etc.) in a backend-specific way. When it leaves IPA, it is
>> converted back to backend-specific type, in a backend-specific way.
>> Inside IPA, the values are passed using the parameter type, so there is
>> no need to do any type conversions inside IPA. This will help me fix
>> 1487 and I believe it will also help John with his DN cleanup work
>> (because he won't have to care about converting the DNs to and from
>> strings).
>>
>> Turns out it is pretty tricky to do everything right, but I (hopefully)
>> solved all the big issues and will submit the patch soon.

I'm very interested in this work. I too have recognized that we have a
very real structural problem with how we handle the types we use
internally, especially when it corresponds to an external type and
requires conversion. In fact we do a remarkably bad job in this area, we
have conversions which are done ad hoc all over the place. There is no
well established place for the conversions to occur and it's difficult
to know at any point in the code what type to expect.

I faced this problem when trying to do the DN clean-up work. In fact the
biggest hurdle I faced was refactoring the code such that when a dn
enters our system it is converted to a DN object and when it leaves our
system it is converted back to a string representation at the logical
API boundaries.

I have code sitting in a personal branch that does a lot of this. It
also caused me to locate and find all the weird hidden places where
conversions magically occur (a good example being the decorators in the
ldap2 module).

I'd like to work with you on this, see what you've done and maybe we
should compare notes and share code. Also given this is a structural
issue perhaps the devel team should review proposed changes since it's
significant to the architecture.

-- 
John Dennis <jdennis at redhat.com>

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