From dev-return-29749-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Tue Mar 31 10:04:05 2009 Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 61134 invoked from network); 31 Mar 2009 10:04:05 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 31 Mar 2009 10:04:05 -0000 Received: (qmail 35673 invoked by uid 500); 31 Mar 2009 10:04:04 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 35592 invoked by uid 500); 31 Mar 2009 10:04:04 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 35584 invoked by uid 99); 31 Mar 2009 10:04:04 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 31 Mar 2009 10:04:04 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of akarasulu@gmail.com designates 209.85.217.171 as permitted sender) Received: from [209.85.217.171] (HELO mail-gx0-f171.google.com) (209.85.217.171) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 31 Mar 2009 10:03:58 +0000 Received: by gxk19 with SMTP id 19so5676086gxk.1 for ; Tue, 31 Mar 2009 03:03:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=ZRAXgGpfJnVB/77y+RVaKi8ry0IDOtVXhUVF6Qi7Q+Q=; b=hh6DC6toiUc3/dc5FdCBGwupXtgqIMAGoT+lNj4zjHkh4iGjOv3wuTgIScfrsW0uBE NayY+WVzpEnBvyIIwq1/TcWTtQWMK7Wlmo3+SCTUrL54mK3mzF/U82yYIriyBJpRJ/Mp cLuzl5/tba3sIvcMH9ZaS3S9W9BV65t+JMr54= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=vzTeFB24cMP4a50KKaUfVJa/heOZuOZ5L4n7/uJ98FHdMContRhnBjUZp5cISw4AfZ P+3G6nzq+Jznmn0yJ43R8PNN/6frlShSFNRlSKQgPaOCjd1R8qwBX7T2wxQ4mF/KSQgw M7ZkNxuH7xL/6601e2vd9nFPMAC/tn+5SBvDk= MIME-Version: 1.0 Received: by 10.231.16.74 with SMTP id n10mr1308370iba.28.1238493816920; Tue, 31 Mar 2009 03:03:36 -0700 (PDT) In-Reply-To: <49D14DED.5000505@nextury.com> References: <49CF4FE0.9040502@nextury.com> <49CF7567.5040807@gmail.com> <49CFAC1F.9000308@nextury.com> <49D11DAE.1000109@labeo.de> <49D14DED.5000505@nextury.com> Date: Tue, 31 Mar 2009 12:03:36 +0200 Message-ID: Subject: Re: [Client API] Bind Operation From: Alex Karasulu To: Apache Directory Developers List Content-Type: multipart/alternative; boundary=000325574d7a039c5704666750c8 X-Virus-Checked: Checked by ClamAV on apache.org --000325574d7a039c5704666750c8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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. Alex --000325574d7a039c5704666750c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Mar 31, 2009 at 12:55 AM, Emmanu= el Lecharny <e= lecharny@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 des= cribed 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 a= lso 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 s= o, 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 cas= e, you would like to get the cause, so it's not obvious to want an exce= ption.

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 BindRe= sponse 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 hav= e asynchronous IO for bind.=A0 I may be missing something though.=A0 Regard= less I suggest we make sure we consider SASL early on for bind since this m= ay impact the way we use it.=A0 As you know some operations require multipl= e bind request/response interactions to negotiate the authentication.=A0 Th= ere is some kind of state now being associated with the series of bind requ= ests.=A0 In general sasl will have some impact on the bind() requiring at l= east some values to be returned, especially when multiple bind req/resp pai= rs are needed for a single authentication.

Alex

--000325574d7a039c5704666750c8--