directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@apache.org>
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 :
|*bind 
<http://developer.novell.com/documentation/jldap/jldapenu/api/com/novell/ldap/LDAPConnection.html#bind%28int,%20java.lang.String,%20byte%5B%5D,%20com.novell.ldap.LDAPResponseQueue%29>*(int
version, 
java.lang.String dn, byte[] passwd, LDAPResponseQueue 
<http://developer.novell.com/documentation/jldap/jldapenu/api/com/novell/ldap/LDAPResponseQueue.html>
queue)| 


"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
www.iktek.com
directory.apache.org



Mime
View raw message