On Sun, Apr 24, 2011 at 1:07 PM, Emmanuel Lécharny <elecharny@apache.org> wrote:
On 4/24/11 11:42 AM, Alex Karasulu wrote:
Hi Emmanuel,

On Sun, Apr 24, 2011 at 12:24 PM, Emmanuel Lecharny<elecharny@gmail.com>wrote:

SNIP ...
I would suggest we create a shared-ldap-extra-control module, where we will
b able to add the Controls other LDAP server are using. We can have a
package for each LDAP server, assuming they use some special controls not
shared with any other. For shared controls, we can put them in the base

Thoughts ?

We already have something like this: the shared-ldap-extras-codec module
contains a set of non-standard extra controls and extended operations that
we (Apache Directory) would provide our users who can optionally use it with
the API. So if we decide to implement a control and provide it we can
package it into this project.

We chose to group these extra controls and extended operations together into
a single bundle for now so all the extended operations and controls are
registered with the codec in one shot. We could have separated them so we
had 2 projects: a project module for extra controls and a project module for
extra extended operations. However with the limited number of extra
(optional) controls and extended operations we have it was easier to manage
as a group.

We can add more optional controls and extended operations to this module
until we notice a congestion problem and then can break it apart but for now
it perfectly suites our needs.

Is this what you were thinking about?

More or less. The 'extra-codec' name is not easy to deal with for our users.

Correct me if I am wrong but do you mean that it's not an intuitive name where user's can automatically see that this module and it's bundle contains optional (extra) controls and extended operations?
If that's the case then we can change it to be more intuitive. 

At some point, for an extra effort (ie splitting this module in two with explicit names) would probably help.

Yeah that would have been good but there's one extra little PITA problem here. By splitting it you're going to have to have 4 modules. Right now there are 2. One for the API holding the non-opaque control and extop interfaces with specific accessor/mutator pairs to their payloads and the actual codec extension (implementation) which does the work of [de]marshalling to and fro. 

If we break this up into a extras-controls and an extras-extended-ops we'll have created two more new modules not just one for a total of 4 modules to handle them.

Something more to think about.