directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: [Client API] Bind Operation
Date Tue, 31 Mar 2009 10:54:51 GMT

>> In some way, we may consider every operation which returns a response to be
>> either synchronous or asynchronous. Of course, it makes more sense for
>> Search, but we might want to have the same mechanism for bind too.
>> What I have in mind is something like that :
>> - each operation can be blocking or non-blocking
>> - if it's blocking, you get the whole response when the method returns (
>> for instance, resp = search( blah ), where resp might be an iterator )
>> - if it's not blocking, we should pass a listener as a parameter, and the
>> method will call the listener when done.
>> - in this case, we will need more than one listener, as each operation may
>> have its own listener, as you may have a non-blocking search, and a
>> non-blocking add at the same time, though.
>> Right now, I would just make the bind request blocking, as all other atomic
>> operations, but keep the search blocking or non-blocking.
> I think the old Java Netscape API does this 
It does :
java.lang.String dn, byte[] passwd, LDAPResponseQueue 

"Asynchronously authenticates to the LDAP server (that the object is 
currently connected to) using the specified name, password, LDAP 
version, and queue."
> but I am not sure it does this
> for all the LDAP operations.  Regardless it does not hurt at all to have an
> additional overload just for the non-blocking mechanism.
Yup. Except that it takes more time to implement ;)

cordialement, regards,
Emmanuel L├ęcharny

View raw message