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. 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. If we could ditch this, I would be *very* happy !
I'll do my Steve Ballmer here : FSM ! FSM ! FSM !
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
