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
