Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 48732 invoked from network); 31 May 2007 22:41:36 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 31 May 2007 22:41:36 -0000 Received: (qmail 97939 invoked by uid 500); 31 May 2007 22:41:39 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 97910 invoked by uid 500); 31 May 2007 22:41:39 -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 97899 invoked by uid 99); 31 May 2007 22:41:39 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 31 May 2007 15:41:39 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (herse.apache.org: local policy) Received: from [212.27.42.35] (HELO smtp5-g19.free.fr) (212.27.42.35) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 31 May 2007 15:41:34 -0700 Received: from [192.168.0.1] (vol75-3-82-66-216-176.fbx.proxad.net [82.66.216.176]) by smtp5-g19.free.fr (Postfix) with ESMTP id BEACC3AE7 for ; Fri, 1 Jun 2007 00:41:12 +0200 (CEST) Message-ID: <465F4F08.7080905@apache.org> Date: Fri, 01 Jun 2007 00:41:12 +0200 From: Emmanuel Lecharny User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: fr, en MIME-Version: 1.0 To: Apache Directory Developers List Subject: Re: [ApacheDS] Cost of interceptors / BindHandler Chain as an example ... References: <568753d90705311105y421f570asd79a5f58fec13ccd@mail.gmail.com> In-Reply-To: <568753d90705311105y421f570asd79a5f58fec13ccd@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org Hi Enrique, first, I wanted to tell you that you were a "collateral damage", because I used the code you wrote as a way to push my vision on interceptors, not because it's bad code. All your comments are perfectly valids. Enrique Rodriguez a �crit : > > >> 3) the order in which the handler are called will never change : (1) >> check the parameters, (2) handle the authenticator, (3) get the >> context (4) process to the bind operation (5) return the result. In >> this case, we could perectly avoid using a chaining pattern > > > I'm glad to see you find this obvious. The code is pretty neat ! Browsing it was a pleasure !) > I agree the chain can be > removed. However, I must stress, that there is benefit to this > pattern to "divide and conquer" during initial development. Now that > the structure is obvious, the chain can be refactored out of the > picture. Exactly. I think you just get it plain right. > >> At some point, I think that we should discuss the chosen >> implementation and architecture before going for a complex choice, as >> soon as it does not freeze the developpement into a net of mails and >> IRC convo so tight that no code get out of this net. >> >> Don't get me wrong : I have used this BindHandler sample because it >> was simple enough to be used to sustain my opinion, not because the >> code is bad or the ideas are bad. I just think we can go for more >> simplicity if it helps the server to be maintanable, scalable, fast >> and flexible. > > > This is only obvious now that a completely working implementation is > in front of you. Of course. As I said, it's easy to see what's wrong when it has been written, but difficult to do it immediatly right. This is why this is good to discuss the design before writing the code (to a certain extent), and at some point, stop discussing and write the code ("a little less conversation, a little more action"...) Emmanuel