mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <l...@toolazydogs.com>
Subject Re: [MINA 3.0] Initial thoughts on FilterChain
Date Mon, 14 Dec 2009 17:34:06 GMT

On Dec 14, 2009, at 8:56 AM, Emmanuel LŽcharny wrote:

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

Agreed, not a very compelling use case.

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

Yeah, nothing is more frustrating than stepping though layers of  
container code.  That's why I configure my debugger to skip those  
chunks of code so it lands directly in my POJOs.  Anyway, since the  
chains are fixed the filter dispatching code is quite simple:

Filter current = filterChain[state, i++];
current.call(session);


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

Easy, yes, initially and if you're the only developer but not so much  
more easier that your point is self evident.  But remember, we all  
agreed that the developer is doing this to create a state machine.   
The above code is brittle and lacks the explicit states.  I would  
argue that it's an anti-pattern.

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

IMO, it's sloppy and error prone and obfuscates code.  If no one else  
agrees then I'm happy to drop my point.

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

I would argue against this.  Mina is afflicted w/ bloat.  One the  
goals should be to get rid of as many useless "helpful" classes and  
methods as we can.  Either we all agree that adding filters in an ad  
hoc manner is a best practice for network protocol state machines and  
we loose the state machine or we agree that it's an anti-pattern that  
should be avoided.  If the community thinks that ad hoc filters are a  
best practice I'm happy to drop my point.

>>> (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 think it's complex.  The point I was trying to make is that  
it's a brittle and obfuscated implementation of a state machine by its  
very nature.

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


I totally agree with this approach to deciding on the API and am happy  
to help out w/ some protocols, e.g. HTTP and SSL.

I am curious, what project feels that it needs to do an "implicit"  
state machine?  I would love to take a peek at the code.


Regards,
Alan



Mime
View raw message