On Sun, Aug 21, 2011 at 3:09 AM, Alan D. Cabrera <l...@toolazydogs.com>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. I think we're confusing different motives for using filters here. One can add a filter for logging, simulating latency or for actually handling a step in the IO processing of a protocol message. If it's for handling a step in IO processing then I can see how the mechanism for doing so can look like the step of a state machine. However when MINA was originally designed the filters were intended to handle separate concerns. However the filters are also being used in such a way that they're not decoupled now, hence the FSM conversation. > 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. > Can you list some of the good practices you have in mind? > > There are implementation issues as well. Look how complicated the > implementation, sketched by Edouard, gets below. > > +1 > 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. > > Yes I agree about getting this finally resolved. However even though I don't have an answer right now, I think there's a better pattern or combination of patterns we can use but not all of them need to be exposed by the API. I think we should be able to inspect, log, or mimic latency in an existing filter chain dynamically but whether or not this translates to a dynamic filter chain that's another story. Best Regards, -- Alex
