directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [Shared] Thoughts on an M2 release?
Date Mon, 28 Feb 2011 12:07:43 GMT
On Mon, Feb 28, 2011 at 1:32 PM, Emmanuel Lecharny <> wrote:
> On 2/28/11 5:01 AM, Alex Karasulu wrote:
>> Hi folks,
>> The tasks for making controls, extended operations and the protocol
>> codec factory totally pluggable are complete. I was just trying to add
>> a couple archetypes for creating new control or extended operation
>> projects. This might help us rapidly get setup to build new extended
>> operations and controls while also helping our API users. This is low
>> hanging fruit for now but the real work starts up again with making
>> schema's pluggable as bundles.
>> Before moving on to this which we can discuss in another thread, I
>> wanted to check and see if y'all want to push out another milestone
>> release? This way we get something into the hands of our users so we
>> can get feedback.
> Yeah, I'm ok for a M2.
>> Also two other points.
>> (1) We should probably build out an example web application using the
>> LDAP API especially with all the Serializable removal work taking
>> place. It might help validate what we should and should not make
>> Serializable. Plus it might be a good application to show the API in
>> action. Perhaps like a little simple LDAP administrative application.
>> It can go into the manual or into the code examples. WDYT?
> +1.
>> (2) Should we shoot for making the schema pluggable with schema
>> bundles? Right now it's already dynamic. I don't know just how much
>> value this adds but it would remove the need for schema dependency
>> checking by our own system, this would be delegated to the OSGi
>> container to determine what schemas a dependent schema depends on.
>> There are some other benefits around classloaders and isolating the
>> operation of loaded code. I could probably enumerate this better with
>> some sleep :).
> I'm not sure it's necessary for basic schemas.

Yes this would not include the basic schemas, the ones expected out of
the box. I would make only optional schemas use this mechanism.

Schema are imported as static
> files by users. Right now, we request that the schema are converted to LDIF,
> we may want to allow users to import plain OpenLDAP schema files instead.

Yes we still want this capability but we want also to gain from what
you wrote below. It's going to be a balancing act. We need to tread
carefully. There's some benefit there but how much exactly depends on
how we implement this.

> Now, for more elaborated schemas, like those including dedicated
> SyntacCheckers, Normalizers, or comparator, yes, that would be interesting
> to have a way to define a bundle that includes all those loadable elements.

Yes the insulation you get with separate class loaders is a great
thing. To me btw things like triggers and stored procedures are part
of the schema. They will be needed to maintain referential integrity.

> May be for M3 ?

I think this is the safest approach yes.


View raw message