directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [Shared] [LDAP] Pluggable Controls and Extended Operations
Date Wed, 26 Jan 2011 12:51:12 GMT
On Wed, Jan 26, 2011 at 1:02 PM, Emmanuel Lecharny <> wrote:
> On 1/26/11 11:42 AM, Pierre-Arnaud Marcelot wrote:
>> On 26 janv. 2011, at 05:51, Alex Karasulu wrote:
>>> Hi y'all,
>>> So the big question is: How do we make Controls pluggable in the codec?
>>> But first the other question of, "WHY bother?" was briefly mentioned
>>> in another email.
> Let me add some background here.
> First of all, we have to distinguish Controls and ExtendedOperations.
> Extended Operation are server specific, and aren't supposed to be portable.

Thanks for adding these points.

I use an analogy that works well for me here. Extended ops are
analogous to ioctls, the catch all for operations not fitting into the
file motif in UNIX device land. You can't use the standard read,
write, and seek operations associated with files on a media changer
for example to change tapes in a tape drive, so you use ioctls to
issue commands specific to that device. Extended operations are LDAP's
ioctls. When the standard LDAP access model cannot be used to perform
DSA specific operation, you use an extended operation.

However you can still have portability but there is no guarantee that
every server supports it. Likewise with controls there's no guarantee.
This is why LDAP servers expose which controls and extended operations
they support via the RootDSE.

Controls on the other hand just modify the behavior, the semantics, of
existing operations like Search.

> Controls, on the other hand, are mostly generic, used across servers. They
> are used on the server side and on the client side.

Not necessarily. Some controls can be server specific. Both extended
operations and controls are portable, in that client can handle them,
and they can be issued to any server. Yet servers may not support the
features they are associated with and decline performing the operation
or in the case of controls just ignore it if it's not critical.

> In any case, we should not expose any of the internal mechanisms used to
> encode or decode controls or extended operation to the users, so some
> decoupling is necessary. Also one point to consider is that we may want to
> be able to add new controls, without having to release a new version of the
> API, like by using a plugin for that purpose.

Exactly! Well said.

>>> I will recap and clarify more here. It's clients
>>> using the codec that really need pluggable controls and extended
>>> operations. We cannot implement all the controls and extended
>>> operations users of the client API will need or conceive of. So the
>>> client must be extensible by allowing new controls and extended
>>> operations to be defined. To make the client extensible this way, the
>>> codec must have a plugin mechanism to be able to encode/decode new
>>> control and extended operations.
>>> What about the server?
>>> ===================
>>> The server may be more hard coded, since its out-of-the-box standard
>>> LDAP request handlers must contain handling logic to process common
>>> controls. If standard request handlers are made pluggable as well,
>>> then these can be replaced to handle controls we have not thought
>>> about. The server does not hard code extended requests since it's got
>>> a handler mechanism to manage that, although how good the mechanism
>>> is, is yet another question.
>>> Techniques For Plugging in Controls and Extended Ops
>>> =============================================
>>> OSGi is great here but we're not ready to run in the environment yet.
>>> Regardless though we can create an instance of Felix inside the codec
>>> just to make controls and extended operations pluggable. But I don't
>>> know how crazy a thought this is.
>> Indeed it could be a first step, instead of moving the whole server to
>> OSGI.
> Atm, if we think about the API, I would not go into this direction, until
> the server itself uses felix. Although, for the existing codec, I see no
> reason not to make them separate modules. But it might be overkilling for
> standard controls too...

I'd package standard controls, like ManageDsaIT, (non-codec classes
ONLY) within the model, keeping the codec classes like the grammars,
containers, and decorators, out of view inside the codec. LDAP API
users need to be able to use ManageDsaIT controls so it must be
exposed but need not be kept in it's own bundle.

Only API user provided, or ADS specific controls and extended
operations need to be pushed into their own bundles to be loaded when

>>> In the vanilla configuration I'd go with something simple that does
>>> not conflict with the OSGi path. There can be a registration
>>> mechanism, where "SOMETHING" registers, new controls and extended
>>> operations with the codec. The codec will have to manage these
>>> registrations and leverage them to instantiate new control and
>>> extended request objects needed for encoding and decoding operations.
>>> I said "SOMETHING" above since this could be a bundle activator in the
>>> OSGi environment packaged into control and extended operation bundles,
>>> or a separate piece of code in the vanilla JSE environment that with
>>> configuration information loads jars from some path, specifically
>>> loading certain classes for controls/extended ops and registering them
>>> with the codec. We should isolate this registration code so when/if we
>>> switch over to the OSGi environment this functionality can be
>>> jettisoned easily. I'm thinking we might be better off just embedding
>>> an OSGi container (Felix) into the client. Felix for example is not
>>> that big size wise, we don't have to write more yuky code that gets
>>> thrown away later, and we gain some experience while enabling these
>>> extension points without impacting code above it.
>> Sounds like a good idea to me.
>> We could also use Karaf as OSGI container. I remember Guillaume Nodet
>> offered his help in that area in a previous thread on the ML (not long ago).
> That's an option, right. Now, the question is how long will it take to get
> it injected in the API...

The mini-Felix embedding within the codec might be trivial. Need to
play with it once we get shared sorted out. We could take a few hours
to prototype it.

>>> Regardless of how we choose to solve this, these pluggable codec
>>> "elements" need to implement well defined interfaces and conform in
>>> behavior to some expected policy (semantic behavior). We already have
>>> a lot of these interfaces defined inside the codec. It's basically a
>>> codec SPI. We just need to formalize, and organize it better.
>>> Any thoughts on this approach? Or do any alternative approaches come to
>>> mind?
>> I think it's forth trying and we could probably code a small prototype for
>> this to see if it suits our needs.
> Yep. I would also first decouple the implementation (and more specifically
> the value codec) from the API. Somehow, what we did for the messages. When
> we get it working, then we can start thinking about using a container.

This is what I am thinking as well. One step at a time.

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

View raw message