On Fri, Jul 1, 2011 at 5:58 PM, Alan D. Cabrera <[email protected]> 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 >
Hi, 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 : http://s.apache.org/A9W 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 ? Julien
