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?
Regards,
Alan
