[Freeipa-devel] Fwd: Type conversions

[Jan Cholasta]

Dne 9.1.2012 16:01, John Dennis napsal(a):
> 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.
>

Ticket: https://fedorahosted.org/freeipa/ticket/2265

Honza

-- 
Jan Cholasta