Re: [ApacheDS] Cost of interceptors / BindHandler Chain as an example ...

[Emmanuel Lecharny <el...@gmail.com>]

Hi guys,

as a perfect exemple of what I wrote about interceptors, I can use the
BindHandler chain to exhibit some of the problems this pattern
carries.

1) Debugging nightmare : The BindHandler chain is a composition of 6
handlers. When commuting from one handler to the next one, you have to
pass through 4 levels of calls into MINA (which means if you don't
have the sources, your are blind). The only way to step through those
handlers is to *know* which is next into the chain, and as this chain
is supposed to be dynamic (at least theorically), can be more than
tricky. And in this case, you will have to set 7 breakpoints...

2) If you are using Simple authentication, you must go through SASL
configuration and handling. Costly ...

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

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.

IMHO, of course !!!

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [ApacheDS] Cost of interceptors / BindHandler Chain as an example ...

[Emmanuel Lecharny <el...@apache.org>]

Hi Enrique,

first, I wanted to tell you that you were a "collateral damage", because 
I used the code you wrote as a way to push my vision on interceptors, 
not because it's bad code. All your comments are perfectly valids.

Enrique Rodriguez a écrit :

> <snip/>
>
>> 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.  

The code is pretty neat ! Browsing it was a pleasure !)

> 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
> picture.

Exactly. I think you just get it plain right.

>
>> 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.

Of course. As I said, it's easy to see what's wrong when it has been 
written, but difficult to do it immediatly right. This is why this is 
good to discuss the design before writing the code (to a certain 
extent), and at some point, stop discussing and write the code ("a 
little less conversation, a little more action"...)

Emmanuel

Re: [ApacheDS] Cost of interceptors / BindHandler Chain as an example ...

[Enrique Rodriguez <en...@gmail.com>]

On 5/31/07, Emmanuel Lecharny <el...@gmail.com> 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
picture.

> 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.

Enrique

Re: [ApacheDS] Cost of interceptors / BindHandler Chain as an example ...

[Alex Karasulu <ak...@apache.org>]

On 5/31/07, Emmanuel Lecharny <el...@gmail.com> wrote:
>
> Hi guys,
>
> as a perfect exemple of what I wrote about interceptors, I can use the
> BindHandler chain to exhibit some of the problems this pattern
> carries.
>
> 1) Debugging nightmare : The BindHandler chain is a composition of 6
> handlers. When commuting from one handler to the next one, you have to
> pass through 4 levels of calls into MINA (which means if you don't
> have the sources, your are blind). The only way to step through those
> handlers is to *know* which is next into the chain, and as this chain
> is supposed to be dynamic (at least theorically), can be more than
> tricky. And in this case, you will have to set 7 breakpoints...


Yes I don't like this at all.  I was not going to allow the merge with this
code but I let it
pass this time since it can be refactored out later.  This pattern is being
used far excessively
like a sledge hammer on finishing nails and as you state debugging it is a
PITA.

2) If you are using Simple authentication, you must go through SASL
> configuration and handling. Costly ...
>
> 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


+1

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.


Alex