directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: Control interface
Date Mon, 31 Jan 2011 15:01:55 GMT
Also inline ...

On Mon, Jan 31, 2011 at 4:24 PM, Emmanuel L├ęcharny <>wrote:

> Comments inline...
> On 1/31/11 2:59 PM, Alex Karasulu wrote:
>> (3) Regardless of what is stored in the value, no application can just use
>> it as is without some kind of component to decode, parse, or interpret
>> this
>> binary data. It's useless to API users otherwise. It's opaque according to
>> LDAP, but there has to be some meaning to make use of this content, and
>> that
>> always requires some code to convert that binary data into usable
>> information. A useful representation to an API user is a parameterized
>> representation making the opaque structure transparent.
> I can imagine a use case where someone has 2 LDAP servers, he get some
> response from server A, with a control he does not know anything about, and
> has to send the value stored into the control without having to decode it,
> to send it as a control in a request sent to server B.
> Ok, a bit far fetched, but this *can* be a use case.
I absolutely agree that it is possible and we have to handle this case. Just
putting all the points on the table for discussion.

> But let's think about the replication control now. It works in a way we get
> a cooie from the server we are contacting, and we are supposed to send this
> cookie back to the server. What is in the cookie is irrelevant to the
> client. Only the server  knows about it. If the client just have to do a
> getValue() to get the cookie, and a setValue( cookie ) to store it in the
> request control, then we don't need to define a specific control : using a
> basic control with the correct OID and criticality is enough.
Doing this for this one case, now exposes all cases. Why not just have a
getCookie()? And in fact, in one or more of the replication controls this is
in fact the case.

Also I'm getting a new idea. Not only simple storage properties need to be
exposed on these custom control interfaces, they can expose methods that
return yet another control in a chain.

Here in this scenario, we're getting a cookie as the opaque value. But how
is that value sent off to another server for example? Is it as the same
control just passed thru, or is it packaged in another control type? Or are
both cases possible?

Say both cases are possible. The ? which extends Control introducing new
properties, can also add new methods that return other Control objects that
can then be encoded accordingly by the codec.

In the simple case of just sending the control back out the door as is. Then
it's merely handed back to the codec which can see the value and encode it
for you.

Assuming we have access to the getValue() setValue() methods of course...
Please don't think I am pushing on this issue. In the end whatever we chose
to be pragmatic we can go with that. I'm just taking a slight devil's
advocate position here to reveal all possibilities.

Again I think we've codec to this getValue/setValue/hasValue way because
JNDI made it the only reality. We can if we like break from it using some
coding techniques. How though does this translate pragmatically?

(1) The codec layer should not return non-decorator objects to user code but
should not reveal that it is returning a decorator, they should only extend
our model Control interface.

(2) Unknown to users, the value is there, it's just hidden from view.

(3) Controls without a specific type hence with no factory registered with
the codec, can just be seen as simple Control implementations, yet without
the value exposed. Underneath the hood the codec can handle the value.

I agree. But closing this door also leads to some situation like the one I
> mentionned.
Yep, our main problem, is if this value needs to be transformed into some
other control, or packaged into some other control, as an opaque value, then
we cannot really do this that easily without exposing it in the Control

Presume we have a control that has no factory, no subtype of the model's
Control interface. So we currently default to using a simple ControlImpl
implementing Control, to represent it. There's no extra interface here on
Control to provide a method to ask for a transformed type or the value. We
kind of had this problem with transforming to JNDI Controls, which is not
the same exact problem but a little similar. So for this case we added
additional methods to the codec service to transform the model Control into
the JNDI Control that does expose the value.

While writing this I am getting more optional ideas:

(1) Create a new interface called OpaqueControl which although not a
Decorator, exposes only access to a copy of the value? We can ask for this
OpaqueControl from the codec service.

(2) Leverage the existing methods toJndiControl on the codec service which
gives us a JNDI version that has access to the value.

(3) Directly ask for the encoded value for a control from the codec service
interface as a general purpose facility and do away with the toJndi/fromJndi
methods on the codec. Instead utilities can be provided to do this for us,
using the getEncodedValue( Control control ) on the LdapCodecService.

This way we can get the value. The only problem is having to have access to
the codec to get it.

> Now, let's be clear : I don't really care, we will cover probably 99.9% of
> all our client usages by not exposing the getValue()/setValue() methods. I'm
> just saying that it may force our users to implement their own classes to
> handle the controls we don't provide, unless we add them in the code base.
> Is this what we want to do ?

I agree we don't want to get stuck in this situation of having to implement
all these controls. But ...

(1) 99.9% of the time we don't have this need to access the value

(2) whatever need we have now is due to us swimming in the old JNDI way

(3) having this default mechanism (ControlImpl) should suite most of the
0.01% cases

(4) the rest of the 0.01% cases that #3 does not handle we can handle by
exposing the encoded value on the codec service interface with one of the
options above

(5) if we do get stuck, we can always add new methods to interfaces in the
API at any point in time, but we can not yank them out at will without

You're best suited to make the call on this matter, because you understand
the codec best, and at the end of the day you're making this magic in the
codec possible. I'm ready to back you on whatever choice you make. I just
want to share all my thoughts with you in case they may help.

Also sorry for this lengthy discussion. I wanted to be thorough.

Alex Karasulu
My Blog ::
Apache Directory Server ::
Apache MINA ::
To set up a meeting with me:

View raw message