On Sun, Apr 24, 2011 at 12:24 PM, Emmanuel Lecharny <firstname.lastname@example.org>
currently, we only implement a few controls, those that we support. In the API, if one wants to use another control to send it to another LDAP server, he has to use an OpaqueControl. So far, so good, except that it's really painful as the value has to be encoded and decoded by the user.
Absolutely and this is why we groked the pain of having a plugin architecture using OSGi to load bundles that add additional controls and extended operations. Users can add explicit (none opaque) handling of controls and extended operations by extending the codec.
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 model.
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?