directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: Controls packages...
Date Fri, 04 Feb 2011 17:01:55 GMT
On Fri, Feb 4, 2011 at 11:24 AM, Emmanuel Lecharny <> wrote:
> Hi guys,

Can we please stop creating new threads on this topic? We've got
several open on Controls. We're distributing the conversation across
all of them.

> I have checked the new packages organisation for control, and I'm not sure I
> find it convenient (not blaming anyone here). However, Alex will probably
> continue to work on it, so the best is to keep going for the moment, then
> discuss the result once done. Every discussion atm would be premature, I
> think.
> (I'm more specifically thinking about the extra.controls package)

OK but if you can specify what exactly it is that's bothering you WRT
this organization I can rectify it. Nothing is final, we have freedom
to change package organization. We do not have many constraints that
we MUST follow.

> May be it's just an intermediary step before those extra controls are moved
> to a separate module...

Yes I am putting these under a new package to prepare for a move into
a new bundle/module. However unless people express their issues with
the package layout, they will be preserved when relocated.


Purpose: For ADS specific optional (class II) codec extensions:
controls & extended ops
Present location: shared-ldap
Target location: shared-ldap-extras
Present Pkg Base:
Exported Pkgs:
Private Pkgs:


The shared-ldap-extras bundle is used to contain all optional
non-standard controls and extended operations: usually ones that are
Apache Directory specific.

I chose to go with ldap-extras instead of ldap-ext (for extended),
because ext/extended, being lexicographically close to extended
operation, would cause some confusion. We also have controls, not just
extended operations in this bundle. Plus I wanted to show those
looking at the bundle name to realize this is something extra in
addition to a standard set of functionality.

Now before a soon to arrive 1.0-M1 release, there exists only two
categories of control extensions to the codec:

     (a) replication (syncrepl) controls (5 total)
     (b) password policy controls (1 total)

I don't foresee the total number of extra controls growing
significantly between M1 and a 1.0 GA release. Even if it doubles or
triples the same organization is sufficient. There's no foreseeable
congestion issue to combine and export all public control interfaces
and POJOs in a single package:

This same line of reasoning holds for extra extended operations. The
standard extended operation interfaces will be in the model, and the
implementations built into the codec, in the same way we have already
done with other standard controls like ManageDsaIT.


The codec extension implementation classes which include factories,
decorators, containers, and grammars were placed in the private
packages ending in _impl. I created a package for each category:
syncrepl and ppolicy.

Why use _impl? Really I don't care. I just gave it a short name
instead of creating a deeper package nesting like
oadslm.controls.impl.syncrepl. Can do this too. Packages ending in
_impl are ugly but these are private implementation packages that will
be hidden. Again this does not matter to me. I just don't want to
create deeper nesting or break up each control into it's own package.
It would be overkill for now.

This configuration will sustain us for the life of a shared 1.0. We
might add a few more optional controls for example but not many.
Adding should not be an issue. It's not going to dramatically explode

Users will create their own controls and extended operations and they
can provide these extensions with their own bundles. That's the whole
point to this anyway.  We just need a place for our odd ball controls
and extended operations.

> Ok, I'm leaving now, so don't expect me to be connected during the
> week-end...


View raw message