directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: API / shared merge
Date Tue, 14 Sep 2010 10:53:44 GMT
On Fri, Sep 10, 2010 at 12:59 AM, Emmanuel Lecharny <>wrote:

>  On 9/9/10 9:09 PM, Stefan Seelmann wrote:
>> On Thu, Sep 9, 2010 at 5:11 PM, Emmanuel Lecharny<>
>>  wrote:
>>>  Hi guys,
>>> it seems that when I did the big modification (merging all the Messages)
>>> last month, I forgot to uncomment the dsml-parser which is part of
>>> shared.
>>> I had it working by pointing to the ldap-api project, as it now depends
>>> on
>>> it, but that was not enough to be able to build it when uncommented in
>>> the
>>> shared/pom.xml file, as shared does not depend on ldap-api.
>>> However, in my mind, the next step was to integrate the ldap-api project
>>> into shared (well, imo, shared<==>  ldap API up to a point).
>>> Here is what I suggest we do :
>>> - move ldap-client into shared
>>> - rename shared to ldap-api
>>> - move all the DIR-SHARED issues to DIRAPI
>>> - and release ldap-api
>> I agree and would like to discuss some more steps before releasing the
>> API:
>> - should we rename the package names o.a.d.shared or keep it?
> IMO, we should rename it to something like ldapApi
I disagree with making a bulk move like this. Shared is more than just stuff
for the ldap-api. Until we take a full inventory and look at the big picture
and how we will grow with new features and fuctionality that will be shared
verses the code that will become the ldap API we should not make rash SVN
churning moves.

>  - about the number of modules, should we merge some? Especially the
>> ldap-schema* modules contain only 10 classes splitted into 3 modules.
> Yes, definitively yes.

I disagree - not enough information to make this call until we understand
why. Was this done for some dependency coupling reasons? Does this situation
still exist? If not sure but we need to take a look at the whole picture.

>  - the shared-ldap module contains some packages that are not directly
>> related to a client API: aci, sp, trigger, subtree.Should we still
>> keep them in the ldap-api project or move them to a server module?
> aci are likely to be used on the client side, as you may want to manipulate
> them on the browser. The very same for subtree.
+1 good point

> sp and trigger is a bit different, but again, as this is up to the 'client'
> to inject SP and triggers into the server, I *think* they might remain on
> the client API.
Again good point.

>  At last before publishing an API we should decide which classes we
>> consider as public API and which classes are for internal use only.
> Absolutely.

Alex Karasulu
My Blog ::
Apache Directory Server ::
Apache MINA ::
To set up a meeting with me:

View raw message