On Tue, Mar 31, 2009 at 12:42 PM, Emmanuel Lecharny <[email protected]>wrote:
> Alex Karasulu wrote: > >> On Tue, Mar 31, 2009 at 12:55 AM, Emmanuel Lecharny <[email protected] >> >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. Alex
