mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edouard De Oliveira <doe_wan...@yahoo.fr>
Subject Re : [MINA 3.0] filter chains
Date Sun, 21 Aug 2011 18:39:38 GMT


On Aug 20, 2011, at 11:47 PM, Emmanuel Lecharny wrote:

> On 8/21/11 2:09 AM, Alan D. Cabrera wrote:
>> Wow, I totally forgot about these pages.
>> 
>> There's been a fair bit of discussion on this topic on the mailing list before, this
being the need for dynamically modifying filter chains in a session that's already being used. 
It is my assertion that it is an anti-pattern that signals the need for a state machine. 
Getting a protocol right on both network endpoints is very hard and dynamic chains make it
even more difficult and error prone.  APIs should promote good practices.
>> 
>> There are implementation issues as well. Look how complicated the implementation,
sketched by Edouard, gets below.
>> 
>> Normally I'm a let a thousand flowers bloom kind of guy.  But, as you know, I've
been a strong advocate of thinning Mina's bloated class library.  I find it difficult justifying
CoW chains in a library that people already find bewildering.
>> 
>> Just my 2 cents.  Let's get this finally resolved as this topic seems to pop up
on a regular basis.
> IMHO, we usually don't need a dynamic chain. There is little to no reason to have it.
One objection could be that one may want to inject a log filter on the fly.

>When one really thinks about it one never just james a log filter in on the fly.  Logging
a network endpoint requires a fair bit of thought, where does it go in the chain, where does
it >log to, how chatty it is, etc.  Usually, it's always in the chain waiting to be turned
on by management bits.  With that said, we're talking about a simple two state FSM, on/off.


Log is a bad filter example we know it from long ago we should use some instrumentation like
tools to make it efficient but something configurable at runtime easily would be even better

But i'm feeling more and more confused by the fsm need : as you said some management bits
in the session can switch on/off some filters why do we want to complicate the coder 's life
using a two state FSM (in the case of multiple filters it would generate  a much more complicated
FSM that the coder would have to describe with code ... better ?) ?

Do you want the fsm to control the flow between filters (state=filter ?) or do you want your
fsm to control if a filter is active ?

> But first, designing a API just to allow such a purpose seems a bit an overkill to me,
and second, I wold rather prefer creating a new session, copying an existing one, if we really
need to do that.
> 
> MINA 2.0 currently has a this functionality, and frankly, it kills when it comes to debug
an application. A debugging session becomes a pain in the butt, as you have to step in an
extra layer before going into the next filter.

> Modern IDEs can be configured to not step into code that resides in certain packages. 
Just an academic observation.

> If we could ditch this, I would be *very* happy !
> 
> I'll do my Steve Ballmer here : FSM ! FSM ! FSM !

Go baby go!


Regards,
Alan

Mime
View raw message