directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@apache.org>
Subject Re: Controls handling in the API
Date Sun, 24 Apr 2011 09:42:30 GMT
Hi Emmanuel,

On Sun, Apr 24, 2011 at 12:24 PM, Emmanuel Lecharny <elecharny@gmail.com>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?

Regards,
Alex

Mime
View raw message