Controls handling in the API

[Emmanuel Lecharny <el...@gmail.com>]

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.

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 ?

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: Controls handling in the API

[Alex Karasulu <ak...@apache.org>]

On Sun, Apr 24, 2011 at 3:11 PM, Emmanuel Lécharny <el...@apache.org>wrote:

> On 4/24/11 12:17 PM, Alex Karasulu wrote:
>
>> </snip>
>>
>> At some point, for an extra effort (ie splitting this module in two with
>>
>>> explicit names) would probably help.
>>>
>>
>> Yeah that would have been good but there's one extra little PITA problem
>> here. By splitting it you're going to have to have 4 modules. Right now
>> there are 2. One for the API holding the non-opaque control and extop
>> interfaces with specific accessor/mutator pairs to their payloads and the
>> actual codec extension (implementation) which does the work of
>> [de]marshalling to and fro.
>>
>> If we break this up into a extras-controls and an extras-extended-ops
>> we'll
>> have created two more new modules not just one for a total of 4 modules to
>> handle them.
>>
>> Something more to think about.
>>
>
> I wasn't thinking about having 2 distinguished modules, but something like
> extra-extensions could be better. I don't really know, except that
> extra-codec does not fit.
>
> At least, I wanted to ope a discussion around this.


I'm open to anything that brings more clarity. I agree that extras-codec is
not very intuitive at describing what exactly is contained in the module.

Regards,
Alex

Re: Controls handling in the API

[Emmanuel Lécharny <el...@apache.org>]

On 4/24/11 12:17 PM, Alex Karasulu wrote:
> </snip>
> At some point, for an extra effort (ie splitting this module in two with
>> explicit names) would probably help.
>
> Yeah that would have been good but there's one extra little PITA problem
> here. By splitting it you're going to have to have 4 modules. Right now
> there are 2. One for the API holding the non-opaque control and extop
> interfaces with specific accessor/mutator pairs to their payloads and the
> actual codec extension (implementation) which does the work of
> [de]marshalling to and fro.
>
> If we break this up into a extras-controls and an extras-extended-ops we'll
> have created two more new modules not just one for a total of 4 modules to
> handle them.
>
> Something more to think about.

I wasn't thinking about having 2 distinguished modules, but something 
like extra-extensions could be better. I don't really know, except that 
extra-codec does not fit.

At least, I wanted to ope a discussion around this.


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: Controls handling in the API

[Alex Karasulu <ak...@apache.org>]

On Sun, Apr 24, 2011 at 1:07 PM, Emmanuel Lécharny <el...@apache.org>wrote:

> On 4/24/11 11:42 AM, Alex Karasulu wrote:
>
>> Hi Emmanuel,
>>
>> On Sun, Apr 24, 2011 at 12:24 PM, Emmanuel Lecharny<elecharny@gmail.com
>> >wrote:
>>
>>
SNIP ...


>  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.


Correct me if I am wrong but do you mean that it's not an intuitive name
where user's can automatically see that this module and it's bundle contains
optional (extra) controls and extended operations?

If that's the case then we can change it to be more intuitive.

At some point, for an extra effort (ie splitting this module in two with
> explicit names) would probably help.


Yeah that would have been good but there's one extra little PITA problem
here. By splitting it you're going to have to have 4 modules. Right now
there are 2. One for the API holding the non-opaque control and extop
interfaces with specific accessor/mutator pairs to their payloads and the
actual codec extension (implementation) which does the work of
[de]marshalling to and fro.

If we break this up into a extras-controls and an extras-extended-ops we'll
have created two more new modules not just one for a total of 4 modules to
handle them.

Something more to think about.

Alex

Re: Controls handling in the API

[Emmanuel Lécharny <el...@apache.org>]

On 4/24/11 11:42 AM, Alex Karasulu wrote:
> Hi Emmanuel,
>
> On Sun, Apr 24, 2011 at 12:24 PM, Emmanuel Lecharny<el...@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?

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

Re: Controls handling in the API

[Alex Karasulu <ak...@apache.org>]

Hi Emmanuel,

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