directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [Client API] Bind Operation
Date Tue, 31 Mar 2009 10:51:04 GMT
On Tue, Mar 31, 2009 at 12:42 PM, Emmanuel Lecharny <>wrote:

> 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.

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.


View raw message