Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 55502 invoked from network); 12 Mar 2007 01:53:26 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 12 Mar 2007 01:53:26 -0000 Received: (qmail 77925 invoked by uid 500); 12 Mar 2007 01:53:35 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 77694 invoked by uid 500); 12 Mar 2007 01:53:34 -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 77678 invoked by uid 99); 12 Mar 2007 01:53:34 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 11 Mar 2007 18:53:34 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of akarasulu@gmail.com designates 66.249.90.176 as permitted sender) Received: from [66.249.90.176] (HELO ik-out-1112.google.com) (66.249.90.176) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 11 Mar 2007 17:53:23 -0800 Received: by ik-out-1112.google.com with SMTP id c21so1508364ika for ; Sun, 11 Mar 2007 18:53:01 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=R1KreUxYyYFCe5eDxPpEBVIluSfNCpOFT2FPbNkzP/7ThMQjjUrQmO29ypMjMH5PdOqEwqMYLRjaQAm6vwEBye+pW9PvjeRMbr8oXcva65BcQojCCTzytv7IM/qQ2/cZ9Ri61BkSUS/d9AOsp5E9A2hZhElenHp0qneQtYC++m8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=dj1JXnqjnCBRTxkXt60ff45PUk4zhJ/QBbptLpc8g3QReOuUP5r0iumvDrarnPoy3YtcWK82AJjwx5u824+M19junTHNSex3E+/frZFAZHrvAVRKUCrIIGGfhDg+t7wQ705xlB2JtXBY40BIcDgvoRzW2sT+t/QwLYjOSC+s/iY= Received: by 10.70.113.16 with SMTP id l16mr9229902wxc.1173664380600; Sun, 11 Mar 2007 18:53:00 -0700 (PDT) Received: by 10.70.78.18 with HTTP; Sun, 11 Mar 2007 18:53:00 -0700 (PDT) Message-ID: Date: Sun, 11 Mar 2007 20:53:00 -0500 From: "Alex Karasulu" Sender: akarasulu@gmail.com To: "Apache Directory Developers List" , erodriguez@apache.org Subject: Re: [LDAP] Merging server-ssl with protocol-ldap In-Reply-To: <568753d90703111705y3fa75dc5pbc29f26790566c52@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_13692_14589007.1173664380505" References: <568753d90703091316r25322499x6c4a09e7e28f1039@mail.gmail.com> <568753d90703091423n1744e93l3fa3d15b818e8a50@mail.gmail.com> <45F1E8AC.1050309@gmail.com> <568753d90703091810j11199c02x5784c445c3692181@mail.gmail.com> <45F29445.9050503@gmail.com> <568753d90703111601t6a7827fai60698f08e0966668@mail.gmail.com> <568753d90703111636s49de480ch833d5426dd0fe01@mail.gmail.com> <568753d90703111705y3fa75dc5pbc29f26790566c52@mail.gmail.com> X-Google-Sender-Auth: 81ebad287fe68e59 X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_13692_14589007.1173664380505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 3/11/07, Enrique Rodriguez wrote: > > On 3/11/07, Alex Karasulu wrote: > > ... > > It would be one giant class if it wasn't broken up somehow. Also, > there are 2 demux (Hashed Adapters) in there. This is a big change > from just Simple authentication. IMO, breaking it up like this makes > it easier to follow. May be so. I don't know at this point. All I know is following the Kerberos code in a debugging session is not so easy mainly due to the CoR pattern. I have the same problem with the code dealing with interceptors in the core code. Both are problematic and are complex. We can't easily use interceptors here without adding interceptor > infrastructure, while MINA has the IoHandlerChain already. What do you mean by interceptor "infrastructure"? Other than > the fact that the Interceptors are more flexible (eg Spring config), > the IoHandlerChain is "fixed"; you can think of it as a subset of the > Interceptor functionality and since Trustin worked on both, they are > similar in semantics. Yes I feel that they do have the same semantics. Except for some subtle differences which I touch upon below. I think once you get used to it, it won't be > hard to follow. Probably but is there some other better way is what I am asking. To me both these interceptors and CoR have the same issues since they do similar things. It's a matter of executing a discrete set of operations in some order to handle a work flow. Interceptors force you to attempt to perform each operation (same length fixed chain where some links just do nothing) and CoR has a custom chain for each work flow with variable length. Interceptors are easier from a configuration standpoint yet CoR may be more efficient. I don't know the hard answers to these questions though. I have debated whether or not to use one over the other in the core. Some days I think the CoR pattern is better than using interceptors. It's about 50/50 for me. However both patterns have similar problems and the same amount of complexity. Also, both DNS and Kerberos use IoHandlerChain's. > For Kerberos, in particular, there is no way I would want to remove > the IoHandlerChain. Well if there is something better out there then I would hope you'd be open to that. As for ease of testing, I don't see how aggregating all the > functionality back into one class would help. Not suggesting that. But if you don't have many items in the chain then why bother with using the pattern. Basically I notice that you use it all over the place and I want to make sure you're not over using it here. Sometimes developers like using patterns when just busting out some simple function can do just as much as 10 additional classes. Just how long is the chain for handling SASL operations? Certainly breaking up > the class into smaller bits in fact increases exposure for testing. Sure I would agree with that. One of my goals is to get an answer to the question: are we better off being consistent with the pattern used regardless of the pattern? Does it make sense to use two separate patterns to do the same thing essentially or are they both warranted due to some subtle detail that I'm overlooking? Alex ------=_Part_13692_14589007.1173664380505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 3/11/07, Enrique Rodriguez <enriquer9@gmail.com> wrote:
On 3/11/07, Alex Karasulu <akarasulu@apache.org> wrote:
> ...

It would be one giant class if it wasn't broken up somehow.  Also,
there are 2 demux (Hashed Adapters) in there.  This is a big change
from just Simple authentication.  IMO, breaking it up like this makes
it easier to follow.

May be so.  I don't know at this point.  All I know is following the Kerberos code in a debugging session is not so easy mainly due to the CoR pattern.  I have the same problem with the code dealing with interceptors in the core code.  Both are problematic and are complex.

We can't easily use interceptors here without adding interceptor
infrastructure, while MINA has the IoHandlerChain already. 

What do you mean by interceptor "infrastructure"?

 Other than
the fact that the Interceptors are more flexible (eg Spring config),
the IoHandlerChain is "fixed"; you can think of it as a subset of the
Interceptor functionality and since Trustin worked on both, they are
similar in semantics.  

Yes I feel that they do have the same semantics.  Except for some subtle differences which I touch upon below.

I think once you get used to it, it won't be
hard to follow.  

Probably but is there some other better way is what I am asking. 

To me both these interceptors and CoR have the same issues since they do similar things.  It's a matter of executing a discrete set of operations in some order to handle a work flow.

Interceptors force you to attempt to perform each operation (same length fixed chain where some links just do nothing) and CoR has a custom chain for each work flow with variable length.  Interceptors are easier from a configuration standpoint yet CoR may be more efficient.  I don't know the hard answers to these questions though.

I have debated whether or not to use one over the other in the core.  Some days I think the CoR pattern is better than using interceptors.  It's about 50/50 for me.  However both patterns have similar problems and the same amount of complexity.

Also, both DNS and Kerberos use IoHandlerChain's.
For Kerberos, in particular, there is no way I would want to remove
the IoHandlerChain.

Well if there is something better out there then I would hope you'd be open to that.

As for ease of testing, I don't see how aggregating all the
functionality back into one class would help.  

Not suggesting that.  But if you don't have many items in the chain then why bother with using the pattern.  Basically I notice that you use it all over the place and I want to make sure you're not over using it here.  Sometimes developers like using patterns when just busting out some simple function can do just as much as 10 additional classes.

Just how long is the chain for handling SASL operations?

Certainly breaking up
the class into smaller bits in fact increases exposure for testing.

Sure I would agree with that.

One of my goals is to get an answer to the question: are we better off being consistent with the pattern used regardless of the pattern?  Does it make sense to use two separate patterns to do the same thing essentially or are they both warranted due to some subtle detail that I'm overlooking?

Alex

------=_Part_13692_14589007.1173664380505--