mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: Re : [MINA 3.0] filter chains
Date Sun, 21 Aug 2011 19:24:58 GMT
On 8/21/11 8:39 PM, Edouard De Oliveira wrote:
> 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
> 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 ?

The FSM obviously will control the flow. The FSM can also check if the 
filter is active, but this is an extra feature, IMHO.

Emmanuel L├ęcharny

View raw message