directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enrique Rodriguez" <>
Subject Re: [ApacheDS] Cost of interceptors / BindHandler Chain as an example ...
Date Thu, 31 May 2007 18:05:29 GMT
On 5/31/07, Emmanuel Lecharny <> wrote:
> ...
> 2) If you are using Simple authentication, you must go through SASL
> configuration and handling. Costly ...

This is temporary.  The configuration should be set once per session,
in the handler's sessionCreated() method.  Then ConfigureChain can be
totally removed.  I left it this way because there is a mess between
the handler, the SessionRegistry, and the DiagnosticUIHandler, which,
IMO, should be deleted.  I felt moving more code into there would make
things worse.  In short, the SessionRegistry is redundant with
functionality in MINA but there are some deps due to
DiagnosticUIHandler and dealing with that was outside the scope of
delivering SASL functionality.

> 3) the order in which the handler are called will never change : (1)
> check the parameters, (2) handle the authenticator, (3) get the
> context (4) process to the bind operation (5) return the result. In
> this case, we could perectly avoid using a chaining pattern

I'm glad to see you find this obvious.  I agree the chain can be
removed.  However, I must stress, that there is benefit to this
pattern to "divide and conquer" during initial development.  Now that
the structure is obvious, the chain can be refactored out of the

> At some point, I think that we should discuss the chosen
> implementation and architecture before going for a complex choice, as
> soon as it does not freeze the developpement into a net of mails and
> IRC convo so tight that no code get out of this net.
> Don't get me wrong : I have used this BindHandler sample because it
> was simple enough to be used to sustain my opinion, not because the
> code is bad or the ideas are bad. I just think we can go for more
> simplicity if it helps the server to be maintanable, scalable, fast
> and flexible.

This is only obvious now that a completely working implementation is
in front of you.


View raw message