directory-dev mailing list archives

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