mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <l...@toolazydogs.com>
Subject Re: [MINA 3.0] Initial thoughts on FilterChain
Date Mon, 14 Dec 2009 16:43:17 GMT

On Dec 14, 2009, at 1:19 AM, Emmanuel Lecharny wrote:

> Ashish a écrit :
>>> Agreed, the SM approach should cover all cases; even the logging  
>>> case in
>>> your subsequent post.
>>> So with that said, would it not make sense to have a set of fixed  
>>> filter
>>> chains w/ each chain representing a state rather than a bucket of  
>>> filters
>>> with each filter deciding the next filter to execute?
>> Sorry , but I am confused :-(
>> can you help me understand how the Filter chains as a state would  
>> work?
>> Here is a simple Chain. The one with * can be dynamically
>> added/removed. Logging filter could be added at multiple places
>> Acceptor -> BlackList Filter -> Logging Filter* -> Throughput Filter*
>> -> Executor Filter -> Codec -> Logging Filter *
>> ->IoHandler
>> Now how would the suggested approach work??
> If I understand Alan, the idea is that the transitions are managed  
> by the SM handler. As state are static, transitions just depend on  
> th context, so an external engine can call the next state  
> considering the current context. In this case, states don't have to  
> know which is the next state, because it's computed in the SM engine.
> It's a typical SM approach, but I'm not sure that it's convenient  
> for us (see my other reply).

Thanks Emmanuel, I think this accurately reflects my thinking.  I  
think that the crux of our discussion lies on the point of whether  
filters need to be injected in an ad hoc fashion.  If so then SM is  
probably not the way to go.


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