On 4/24/11 11:42 AM, Alex Karasulu wrote:
Hi Emmanuel,
On Sun, Apr 24, 2011 at 12:24 PM, Emmanuel Lecharny<[email protected]>wrote:
Hi guys,
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.
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. At some point, for an extra effort (ie splitting this module in
two with explicit names) would probably help.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
