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] Initial thoughts on FilterChain
Date Sat, 02 Jul 2011 07:32:19 GMT
On Fri, Jul 1, 2011 at 5:59 PM, Alan D. Cabrera <list@toolazydogs.com> 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?

For simple cases this might "seem" like overkill but IMHO I think it's
better always to be explicit. It's clear what is happening. Surprise
Emmanuel that you did not jump for this you are Mr. State Machine :-).

Regards,
Alex

Mime
View raw message