On 3/11/07, Enrique Rodriguez <email@example.com> wrote:
On 3/11/07, Alex Karasulu <firstname.lastname@example.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"?
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
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?