Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (herse.apache.org: domain of enriquer9@gmail.com designates
 209.85.132.242 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=Mf10wRFJZgUQokfZtK+P/xAcsyQbde/E1lsNgTe8hRM2AsRkWYX8Z6gSNQmKT6tQGaHpY/Y78VDKYY39F+RZdS1V++Yn4krfqrxwbeQYPRhajQ3Mira2U6hevtMjZdkN1lDq/T0oREnc7RQBLpbplYvxfpYGh9eJrEnKbFkHA74=
Message-ID: <568753d90703111933m4fe74ee0v9d42eab5138553b2@mail.gmail.com>
Date: Sun, 11 Mar 2007 18:33:57 -0800
From: "Enrique Rodriguez" <enriquer9@gmail.com>
Reply-To: erodriguez@apache.org
To: "Apache Directory Developers List" <dev@directory.apache.org>
Subject: Re: [LDAP] Merging server-ssl with protocol-ldap
In-Reply-To: <a32f6b020703111853h6c43887ck922472c26aa56fa3@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <568753d90703091316r25322499x6c4a09e7e28f1039@mail.gmail.com>
	 <45F1E8AC.1050309@gmail.com>
	 <568753d90703091810j11199c02x5784c445c3692181@mail.gmail.com>
	 <45F29445.9050503@gmail.com>
	 <568753d90703111601t6a7827fai60698f08e0966668@mail.gmail.com>
	 <a32f6b020703111621q4a1c2d5av6651451e3d3ab8ee@mail.gmail.com>
	 <568753d90703111636s49de480ch833d5426dd0fe01@mail.gmail.com>
	 <a32f6b020703111649s45a3058fk3340627214be17ec@mail.gmail.com>
	 <568753d90703111705y3fa75dc5pbc29f26790566c52@mail.gmail.com>
	 <a32f6b020703111853h6c43887ck922472c26aa56fa3@mail.gmail.com>

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