On Tue, Mar 31, 2009 at 12:42 PM, Emmanuel Lecharny <elecharny@apache.org> wrote:
Alex Karasulu wrote:
On Tue, Mar 31, 2009 at 12:55 AM, Emmanuel Lecharny <elecharny@apache.org>wrote:

Stefan Zoerner wrote:

Emmanuel Lecharny wrote:

 some first thought about the bind operation. I propose 4 methods :
- bind() for an anonymous bind
- bind(String name) for an unauthenticated bind (this is a special case
described in RFC 4513, par 5.1.2)
- bind(String name, String credentials)
- bind(String name, byte[] credentials) Those two methods are standard
bind with a credential as a String or byte[]

We may define a few others, assuming we may want to use some controls. We
also have to deal with SASL bind.

Looks good to me. What about the return value (is it void in all four
cases?) and the case that authentication fails. Throws it an exception, and
if so, is it derived from RuntimeException (I hope so)?

First, let's talk about the return value. We have two cases :
1) authentication succeeded. We will get a BindResponse
2) authentication failed. We will also have a BindResponse, but in this
case, you would like to get the cause, so it's not obvious to want an

So my best guest would be that it's better not to throw an exception.

One more thing : we might want to get a non-blocking mode, where the
BindResponse is not returned but a listener is invoked. We discussed that
option with Alex, and right now, we think it's better to have a blocking
mode for simple operations, and a non-blocking mode for search.

Does it make sense ?

It does not make much sense to me to have asynchronous IO for bind.  I may
be missing something though.  Regardless I suggest we make sure we consider
SASL early on for bind since this may impact the way we use it.  As you know
some operations require multiple bind request/response interactions to
negotiate the authentication.  There is some kind of state now being
associated with the series of bind requests.  In general sasl will have some
impact on the bind() requiring at least some values to be returned,
especially when multiple bind req/resp pairs are needed for a single
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 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.