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:42:05 GMT
Alex Karasulu wrote:
> On Tue, Mar 31, 2009 at 12:55 AM, Emmanuel Lecharny <>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
>> exception.
>> 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
> authentication.
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.

cordialement, regards,
Emmanuel L├ęcharny

View raw message