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 01:53:00 GMT
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

Mime
View raw message