directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <>
Subject Re: [VOTE][RESULTS] Should we merge the DIRSHARED and DIRAPI spaces in JIRA into a single one?
Date Tue, 05 Jul 2011 21:17:26 GMT
On 7/5/11 10:53 PM, Alex Karasulu wrote:
> On Tue, Jul 5, 2011 at 1:01 PM, Emmanuel Lecharny<>  wrote:
>> On 7/5/11 11:47 AM, Pierre-Arnaud Marcelot wrote:
>>> Just to be clear before I make the changes.
>>> Should I merge DIRSHARED into DIRAPI ? or DIRAPI into DIRSHARED?
>>> My choice would be the first option, as Shared is becoming the API.
>>> What's yours?
>> DIRAPI is way better, IMHO.
> I suggest the opposite because of the investment that has gone into
> references for DIRSHARED. And at the end of the day it's still shared
> stuff across both main projects, studio and the server.
I agree for the 'investment', except that it's just a name. From now on, 
the API is what we use in Studio and the server. There is not much we 
don't expose as a generic LDAP API in shared (only what is specific to 
the server, like the triggers and SP).
> There are more
> things that will go into this down the line besides LDAP. If we
> release later we can release just parts of it instead of the whole
> thing: meaning just the ldap api.
That's an option. Most of what is currently Shared is in fact the LDAP 
API. An extra effort could split shared in two parts : the LDAP API 
(most of what is shared atm) and what is specific to the server. It 
would probably worth the effort.
> We can still restructure but we're going to unsettle some references
> we've put even into the code around these issues from the past.
Can you give some exemple ?

>   If
> you're find with doing away with it then I can live with it but we
> will lose more.
We still are in Milestone mode, so there is no need to freeze anything 
here. Having the API being adopted more and more will however lead us to 
expose it as what it is : a replacement for JNDI. Naming it shared is at 
this point misleading. I think this is the rational behind this proposal.

But that does not mean we should not have a new suproject which contains 
what is not part of the LDAP api.

Emmanuel L├ęcharny

View raw message