On Wed, Jan 5, 2011 at 10:55 PM, Emmanuel Lécharny <[email protected]> wrote: > On 1/5/11 5:33 PM, Kiran Ayyagari wrote: >> >> On Wed, Jan 5, 2011 at 9:43 PM, Emmanuel Lecharny<[email protected]> >> wrote: >>> >>> On 1/5/11 4:48 PM, Alex Karasulu wrote: >>>> >>>> On Wed, Jan 5, 2011 at 5:29 PM, Kiran Ayyagari<[email protected]> >>>> 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
