directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@apache.org>
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 <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



Mime
View raw message