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] filter chains
Date Sun, 21 Aug 2011 16:25:42 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.

> 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