mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel LŽcharny <elecha...@gmail.com>
Subject Re: [MINA 3.0] Initial thoughts on FilterChain
Date Mon, 14 Dec 2009 16:56:21 GMT

>> Not necessarily, for three reasons :
>> 1) if the chain is fixed at startup, you can't anymore inject a 
>> LoggingFilter when the server is running. You can only activate or 
>> desactivate it. Not that it's realy a big issue, but it may help in 
>> some case (that also mean we have a way to control the execution. JMX ?)
> One normally doesn't turn on and off things like that on a per message 
> basis.  What I mean by that is that each filter decides to do what it 
> needs to do.  That includes logging.  Constantly injecting logging 
> filters on an ad hoc basis is a very, very, poor practice.

A very, very rare practice, hopefully :) Here, i'm not sure it worth it 
anyway. I really think it's better to enable the filter instead of 
injecting it dynamically. In any case, I'm ready to lose this "feature"...

>> 2) Most important, if we don't have a clue about which is the next 
>> filter in the chain, that leads to problem when debugging, as you 
>> can't know which filter will be called. Ennoying
> Sure you do.  The chains are fixed.  If you know what filter you are 
> and what state you're in you know what filter gets called next from 
> the perspective of the framework.  From the perspective of the filter 
> you shouldn't care what's next, if you do then you've introduce a 
> brittle dependency.  For me that;s usually a red flag that I haven't 
> thought through a design and it needs to be revisited.
Let me clarify my mind : when stepping through filters while debugging, 
I want to be able to jump directly to the next filter. In order to do 
that, code like :

Filter nextFilter = computeNext( session );
nextFilter.call( session );

is mandatory. I don't want to experiment the same pain as with Spring, 
when I have to open two editors, one for my java code, and another one 
to see what is supposed to be my SM. I went through this pain so many 
times in the past with MINA that I don't want to suffer such a pain again...
>> 3) Last, not least, we want to be able to call the next filter in the 
>> middle of a processing :
>> messageReceived() {
>> do blah();
>> if ( condition ) {
>> do anotherBlah();
>> call Next filter();
>> } else {
>> do yetAnotherBlah();
>> call nextFilter();
>> }
>> do endingBlah();
>> }
> That just tells me that you have mixed up two states into one and that 
> you need to expend a little more effort into your state machine design.

 From the user POV, it's way more easy to write code this way than to 
create two (or more) states. The idea is to combine the state machine 
vision with the chain vision. You can express everything with a SM, and 
implement it in a simpler way...
>> Not sure this is possible in another way than with those computed 
>> nextFilter() inside the filters.
> I agree but it's my contention that it's a bad practice that supports 
> an ill thought out protocol.

The biggest advantage is that it eases the implementor work most of the 
cases. Now, it does not preclude that we should not allow someone to 
implement his protocol using a complete state machine. May be we should 
provide both mechanisms :
- one which is driven by the code (ie, the code 'pull' the next step),
- one which is driven by the state machine (your way).

>> (well, t's always possible to express this with more transitions and 
>> states, but t would be more complicated to write filters then...)
> I'm looking at your messageReceived() method and am thinking that you 
> have provided me with a perfect example for state programming.  Only 
> the original author of that method would know what's going on.
Most certainly :) However, this was a complex example, usually, it's way 
more simple.

I don't say that you are plain wrong, in fact, I share most of your 
vision, but I'm just wondering if this would not render the protocol 
implementors way more complex.

I may try to see what would be the impact of the plain SM approach when 
applied on the current implemented protocols.

Thanks !

View raw message