Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 73575 invoked from network); 12 Mar 2007 03:21:23 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 12 Mar 2007 03:21:23 -0000 Received: (qmail 28945 invoked by uid 500); 12 Mar 2007 03:21:31 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 28908 invoked by uid 500); 12 Mar 2007 03:21:31 -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 28896 invoked by uid 99); 12 Mar 2007 03:21:31 -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 20:21:31 -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.82.234 as permitted sender) Received: from [66.249.82.234] (HELO wx-out-0506.google.com) (66.249.82.234) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 11 Mar 2007 19:21:20 -0800 Received: by wx-out-0506.google.com with SMTP id h31so1531453wxd for ; Sun, 11 Mar 2007 20:20:59 -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=i8eHTuiXS7I5lF78drT3cyib24N6eodJNzc7hHKt4j6FGPNRzUElS9omDBbio59SSESEr5f/UIQJSzfnGW1aK/A3saUBKuyK4SRYktoJP09urhh3m9DMKjayFV6tDoMzYPtujxCVpLQ9pZdaqwxp0AqGqblEZKh5TS+oa4tYA5s= 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=fKBAUgMiWvVFgygIJwpv6WbRmDkQF+k/2HCduJZRxGGJHRKqyYE0dBxymiuQsMYzbhx5q5/UHdHGGenvQn6YDNIzlXl9+O/WEGTeH4KnhJSY0NnCNb8O71iDymw2VjQJDDXl2EtlsK+4SmfHc0PwtLl/mr5MyF0NIFPKHj/u8Os= Received: by 10.70.39.5 with SMTP id m5mr9469921wxm.1173669659398; Sun, 11 Mar 2007 20:20:59 -0700 (PDT) Received: by 10.70.78.18 with HTTP; Sun, 11 Mar 2007 20:20:59 -0700 (PDT) Message-ID: Date: Sun, 11 Mar 2007 22:20:59 -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: <568753d90703111933m4fe74ee0v9d42eab5138553b2@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_13980_24314124.1173669659341" References: <568753d90703091316r25322499x6c4a09e7e28f1039@mail.gmail.com> <568753d90703091810j11199c02x5784c445c3692181@mail.gmail.com> <45F29445.9050503@gmail.com> <568753d90703111601t6a7827fai60698f08e0966668@mail.gmail.com> <568753d90703111636s49de480ch833d5426dd0fe01@mail.gmail.com> <568753d90703111705y3fa75dc5pbc29f26790566c52@mail.gmail.com> <568753d90703111933m4fe74ee0v9d42eab5138553b2@mail.gmail.com> X-Google-Sender-Auth: 91de5af8aa1204f5 X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_13980_24314124.1173669659341 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline OK I guess it's just simpler for me to look at the code and try to digest it. Alex On 3/11/07, Enrique Rodriguez wrote: > > On 3/11/07, Alex Karasulu wrote: > > On 3/11/07, Enrique Rodriguez wrote: > > > On 3/11/07, Alex Karasulu wrote: > > > ... > > > We can't easily use interceptors here without adding interceptor > > > infrastructure, while MINA has the IoHandlerChain already. > > > > What do you mean by interceptor "infrastructure"? > > I mean the interfaces and helper classes for supporting the pattern. > For example, "MessageHandler" in MINA demux'ers, "IoFilterAdapter" and > "NextFilter" in the filter chains, and "IoHandlerCommand" and > "NextCommand" in MINA handler chains. You need these to set up the > pattern and, furthermore, they have to have method signatures that > support other MINA classes, such as the passing of the IoSession. > > > ... > > 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. > > I agree with the general idea that it would be nice to have the same > pattern in use, but we come back to the issue that in MINA, both the > Filter chain and the Handler chain are provided for us. Incidentally, > SslFilter and SaslFilter and the overall MINA filter chains are the > same pattern as the handler chains. > > > > 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. > > Yes, I would be open to something better. For example, with OSGi > there is the possibility to allow people to plug-in new features for > chain processing. But MINA doesn't support that today and that would > be the best place to develop such code so others would benefit and > also for the method signature issues I noted above. > > > > 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. > > I think number of links is a simplistic way to look at it. Some links > can do very little, in which case you can mentally "write them off." > By that I mean, you grok that one chain link, understand it, and then > never have to dive into it again. ChainGuard is like that. Other > links may do something complex, such as the one link that does all the > SASL negotiation. Also, as Emmanuel noted, for complex code it just > makes the code easier to follow. > > I don't "use it all over the place." I use it for the BindHandler, > DNS, and Kerberos. And I only apply it when complexity grows to a > point where I think it is warranted. For example, DHCP and NTP don't > use it. In those cases it didn't warrant it. > > > Just how long is the chain for handling SASL operations? > > There are 6 links. 2 of those links include demux'ers. Please keep > in mind that the number of authentication mechanisms quadrupled, not > that the Simple mechanism did much. Perhaps a better comparison would > be that the BindHandler went from 1 class to 18 and that is on top of > SASL support in JDK 1.5. > > > > 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? > > I think the subtle detail is that MINA only supports one. If MINA > filter chains, MINA handler chains, and our Core interceptor service > chain all worked well as one unified pattern, and that one pattern was > supported in MINA, then great, I would use that. > > Enrique > ------=_Part_13980_24314124.1173669659341 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline OK I guess it's just simpler for me to look at the code and try to digest it.

Alex

On 3/11/07, Enrique Rodriguez < enriquer9@gmail.com> wrote:
On 3/11/07, Alex Karasulu < akarasulu@apache.org> wrote:
> On 3/11/07, Enrique Rodriguez <enriquer9@gmail.com> wrote:
> > On 3/11/07, Alex Karasulu < akarasulu@apache.org> wrote:
> > ...
> > We can't easily use interceptors here without adding interceptor
> > infrastructure, while MINA has the IoHandlerChain already.
>
> What do you mean by interceptor "infrastructure"?

I mean the interfaces and helper classes for supporting the pattern.
For example, "MessageHandler" in MINA demux'ers, "IoFilterAdapter" and
"NextFilter" in the filter chains, and "IoHandlerCommand" and
"NextCommand" in MINA handler chains.  You need these to set up the
pattern and, furthermore, they have to have method signatures that
support other MINA classes, such as the passing of the IoSession.

> ...
> 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.

I agree with the general idea that it would be nice to have the same
pattern in use, but we come back to the issue that in MINA, both the
Filter chain and the Handler chain are provided for us.  Incidentally,
SslFilter and SaslFilter and the overall MINA filter chains are the
same pattern as the handler chains.

> > 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.

Yes, I would be open to something better.  For example, with OSGi
there is the possibility to allow people to plug-in new features for
chain processing.  But MINA doesn't support that today and that would
be the best place to develop such code so others would benefit and
also for the method signature issues I noted above.

> > 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.

I think number of links is a simplistic way to look at it.  Some links
can do very little, in which case you can mentally "write them off."
By that I mean, you grok that one chain link, understand it, and then
never have to dive into it again.  ChainGuard is like that.  Other
links may do something complex, such as the one link that does all the
SASL negotiation.  Also, as Emmanuel noted, for complex code it just
makes the code easier to follow.

I don't "use it all over the place."  I use it for the BindHandler,
DNS, and Kerberos.  And I only apply it when complexity grows to a
point where I think it is warranted.  For example, DHCP and NTP don't
use it.  In those cases it didn't warrant it.

> Just how long is the chain for handling SASL operations?

There are 6 links.  2 of those links include demux'ers.  Please keep
in mind that the number of authentication mechanisms quadrupled, not
that the Simple mechanism did much.  Perhaps a better comparison would
be that the BindHandler went from 1 class to 18 and that is on top of
SASL support in JDK 1.5.

> > 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?

I think the subtle detail is that MINA only supports one.  If MINA
filter chains, MINA handler chains, and our Core interceptor service
chain all worked well as one unified pattern, and that one pattern was
supported in MINA, then great, I would use that.

Enrique

------=_Part_13980_24314124.1173669659341--