On Jul 1, 2011, at 8:04 AM, Emmanuel Lecharny wrote:
> 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.
I'm hearing possibility not necessity.
> 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.
> 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.
I'll take a peek at these. Thanks!
Regards,
Alan
