mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@apache.org>
Subject Re: [MINA 3.0] filter chains
Date Sun, 21 Aug 2011 08:58:11 GMT
On Sun, Aug 21, 2011 at 3:09 AM, Alan D. Cabrera <list@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

> 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.

> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message