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 10:17:23 GMT
On Sun, Apr 24, 2011 at 1:07 PM, Emmanuel L├ęcharny <elecharny@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

Mime
View raw message