Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Message-ID: <4D24A979.7070405@apache.org>
Date: Wed, 05 Jan 2011 18:25:13 +0100
From: =?ISO-8859-1?Q?Emmanuel_L=E9charny?= <elecharny@apache.org>
Reply-To: elecharny@apache.org
Organization: The Apache Software Foundation
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
 rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: ADS 2.0 : what, how and when?
References: <4D248407.9020803@gmail.com>
	<AANLkTim7=see6QDPV-abLYs7ZeyYrRfuH=U_P6Ebt-36@mail.gmail.com>
	<AANLkTin-7OH5p2wct5-Q2OhRkzAXtQSyWnyk_dvU8qsU@mail.gmail.com>
	<4D249897.6060305@gmail.com>
 <AANLkTiksHsNC6G=DYdhcB-0etOWW7AwWWr=mM=ysi1nC@mail.gmail.com>
In-Reply-To: <AANLkTiksHsNC6G=DYdhcB-0etOWW7AwWWr=mM=ysi1nC@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

On 1/5/11 5:33 PM, Kiran Ayyagari wrote:
> On Wed, Jan 5, 2011 at 9:43 PM, Emmanuel Lecharny<elecharny@gmail.com>  wrote:
>> On 1/5/11 4:48 PM, Alex Karasulu wrote:
>>> On Wed, Jan 5, 2011 at 5:29 PM, Kiran Ayyagari<kayyagari@apache.org>
>>>   wrote:
>>>> the LdapAPI is already stable and perfectly shielded from the
>>>> internals of shared, so
>>>> I see no issue from a user POV cause they are dependent on the
>>>> LdapConnection
>>>> interface only
>>>>
>>>>
>>> If this is the case then and the client API does not expose any other
>>> shared
>>> interfaces then we're golden here.
>>>
>> I will not be as optimistic, sadly. There are a few things we can improve in
>> the LdapAPI, even if it has demonstrated to be stable when we used it in
>> Studio (yes, you heard me : Studio is now entirely based on the Ldap API
>> !!!)
>>
>> Here is a list of things I think we should add in Ldap API :
>> - make all the API schema aware. This is quite a big part of the job. It has
>> started, we already have a DnFactory, but it's not finished
> if by 'API' if you are referring to client-api then it is already schema aware,
> note that this schema-awareness in client-api is not essential, it is optional

Damn, I'm lagging then :)


> It is required in cases where you build an app which need to do
> perform some operations which require access to schema info e.x Studio
> and replication subsystem
Ok, so we are more "stable" than I thought then !

>> - decouple the network layer from the API. Currently, we use MINA, but some
>> other might want to use Grizzly.
> agreed, but should be a post 2.0 effort

That's an option, true.

>> - adding a better support for Extended Operations and Controls. The set of
>> controls and extOps we are supporting is not enough.
>>
> isn't this mainly a server thing
Sadly, no. Users want to be able to send some server specific ExtOps or 
Controls. Those guys are not defined by any common specification, it's 
even worse, each server may have its own set of controls or ExtOps.

However, we may define some extension point allowing us to design a 
specific control or extOps (for the client side) which is included in 
the API.

This may not be considered as a blocker for a 1.0, I don't know.

It deserves some discussion...

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