directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre-Arnaud Marcelot>
Subject Re: [Shared] [LDAP] Pluggable Controls and Extended Operations
Date Wed, 26 Jan 2011 10:42:36 GMT

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. 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.

> 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).

> 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.

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

View raw message