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? Regards, Alex
