directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <>
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 <> wrote:
> On 1/5/11 5:33 PM, Kiran Ayyagari wrote:
>> On Wed, Jan 5, 2011 at 9:43 PM, Emmanuel Lecharny<>
>>  wrote:
>>> On 1/5/11 4:48 PM, Alex Karasulu wrote:
>>>> On Wed, Jan 5, 2011 at 5:29 PM, Kiran Ayyagari<>
>>>>  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

Kiran Ayyagari

View raw message