mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: [MINA 3.0] Initial thoughts on FilterChain
Date Fri, 01 Jul 2011 15:04:48 GMT
On 7/1/11 4:59 PM, Alan D. Cabrera wrote:
> On Jun 30, 2011, at 4:13 PM, Emmanuel Lecharny wrote:
>> On 6/30/11 9:52 PM, Alan D. Cabrera wrote:
>>> On Jun 30, 2011, at 2:42 AM, Ashish wrote:
>>>> <snip/>
>>>> This does meet some of our requirements, but not all. We can have something
>>>> similar to this and instead of returning true/false
>>>> from Filters, we can return the next step to be executed. Something like
>>>> this
>>>> IoFilter messageReceived(IoSession session, Object message) {
>>>>     // process
>>>>    // see if just to flow with Filter Chain
>>>>    return null; // or something better
>>>>    // or
>>>>    // a diff message detected, calculate next filter based on some app
>>>> specific state
>>>>    return calculateNextFilter(state);
>>>> }
>>>> command is passed back to the chain and it can take care of executing the
>>>> next filter.
>>>> Shall try something similar in sandbox and lets see how it goes :)
>>> I'm not so sure that filters should be in charge of deciding who should be called
next.  I don't think that how the filter stack is assembled should be leaked into the filters
themselves.  The filter should be solely concerned with its task and not have to decide who
gets called next.
>> Not sure, Alan. There are some cases where it's mandatory that a filter select the
next filter to execute : for instance, if your codec produces more than one message, and the
following processing may depend on the message type. Of course, you can use a demux protocol
filter (I don't exactly remember the name of it, so it's from the top of my head, but we use
such a mechanism in ADS), but it's just one option.
> I'm hearing a state machine that's implicitly defined via what gets returned by that
method.  If this is the case would it not be better to have an explicitly defined state machine?

Not necessarily. We can think about a multiple layer decoder which works 
the very same way.

But all in all, in this case, the chain of filters will *be* a state 

I have some ideas (and I even have created some branch years ago: 
http://svn.apache.org/viewvc/mina/branches/mina-new-chain/ and 
http://svn.apache.org/viewvc/mina/branches/mina-new-chain2/) to play 
around this idea.

Emmanuel L├ęcharny

View raw message