directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <>
Subject Re: Controls handling in the API
Date Sun, 24 Apr 2011 10:07:44 GMT
On 4/24/11 11:42 AM, Alex Karasulu wrote:
> Hi Emmanuel,
> On Sun, Apr 24, 2011 at 12:24 PM, Emmanuel Lecharny<>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.

Emmanuel L├ęcharny

View raw message