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
