directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre-Arnaud Marcelot ...@marcelot.net>
Subject Re: [Shared] [LDAP] Pluggable Controls and Extended Operations
Date Wed, 26 Jan 2011 12:54:37 GMT

On 26 janv. 2011, at 13:28, Alex Karasulu wrote:

> On Wed, Jan 26, 2011 at 12:42 PM, Pierre-Arnaud Marcelot
> <pa@marcelot.net> 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. 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).
> 
> I definitely would like to take Guillaume up on his offer however
> Karaf is not really an OSGi container, rather it is a container for
> OSGi containers. It's an environment between the containers running in
> it an the OS which adds some really nice benefits: for example it
> offers an OSGi shell that you can remotely log into via SSH to manage
> your containers and their bundles. I love it.
> 
> Ultimately we probably want to run the server inside Felix, running
> inside Karaf. Using Karaf however is not an option for studio or a
> simple client API.

Yeah sure.
The "Deployer" feature of Karaf made me think it would be very easy for people extending ADS
to add their own controls and extended operations.

> My thought was to programmatically start up an instance of Felix
> within the codec just to enable pluggable controls and extended
> operations between now and when we go full OSGi. If this codec,
> embedding Felix, runs in a simple Java application, or yet in another
> Felix instance, or in Eclipse there's little to no impact. Plus it
> gives us a tiny taste of what we can do before running everything in
> an OSGi container.

Indeed.

>>> 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.
> 
> Yeah we can test it out. That's probably best.
> 
> Thanks,
> -- 
> Alex Karasulu
> My Blog :: http://www.jroller.com/akarasulu/
> Apache Directory Server :: http://directory.apache.org
> Apache MINA :: http://mina.apache.org
> To set up a meeting with me: http://tungle.me/AlexKarasulu


Mime
View raw message