directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <kayyag...@apache.org>
Subject Re: ADS 2.0 : what, how and when?
Date Wed, 05 Jan 2011 17:42:47 GMT
On Wed, Jan 5, 2011 at 10:55 PM, Emmanuel Lécharny <elecharny@apache.org> wrote:
> 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...
these new controls can still be sent by users but they are responsible for the
associated codec(only if that codec is not present in client-api)
So, in a way we support this, but not in a convenient way where
user can say 'add this XXX control or add the control with oid Y.Y.Y'
We might consider adding a control registry on the client side which
will contain
any new controls that are only supported by other LDAP servers.
and yes this is not a blocker for 1.0
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>



-- 
Kiran Ayyagari

Mime
View raw message