mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julien Vermillard <jvermill...@gmail.com>
Subject Re: [MINA 3.0] Initial thoughts on FilterChain
Date Sat, 02 Jul 2011 06:14:01 GMT
On Fri, Jul 1, 2011 at 5:58 PM, Alan D. Cabrera <list@toolazydogs.com> wrote:
> On Jul 1, 2011, at 8:52 AM, Emmanuel Lecharny wrote:
>> On 7/1/11 5:47 PM, Alan D. Cabrera wrote:
>>> On Jul 1, 2011, at 8:04 AM, Emmanuel Lecharny wrote:
>>>> But all in all, in this case, the chain of filters will *be* a state machine.
>>> And here is my point.  They all are really state machines.  Having network
protocols "randomly" choosing chain paths is an anti-pattern.  State machines should be known
and fixed at the time of protocol initiation.
>> Don't get me wrong... I'm not sure anyone here had in mind an implementation which
picks the next filter randomly... Although, that could be funny :)
> To everyone but the person who has to debug what's going on.  ;)
> With that said, why would we want our API make that possible?  Would we not be doing
our user base a service by switching the Mina API to a bona fide state machine with fixed
state chains?
> Regards,
> Alan

I think it's possible to make FilterChain a simple List of Filters
called by the chain and not-chained as we do.
For special usage where the Filter decide which filter to call, the
filter could be called from the "demuxing" filter :

The chain could be stored in the IoService and copied to the session
only if it specifically was modified for this session (Copy on write).
It could save some memory.
Now the *REAL QUESTION* is how we implement SEDA/ExecutorFilter with
this kind of list of filter ?

View raw message