directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject [Shared] [LDAP] Pluggable Controls and Extended Operations
Date Wed, 26 Jan 2011 04:51:28 GMT
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.

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.

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?

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

View raw message