On Aug 21, 2011, at 11:39 AM, 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 better
My observations also apply to instrumentation as well. > 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 ? There's no reason why one could not have a chain of FSMs. You get the exact same behavior with less framework code. Regards, Alan
