directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: [LDAP] Merging server-ssl with protocol-ldap
Date Mon, 12 Mar 2007 03:20:59 GMT
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
>

Mime
View raw message