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
machine.
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.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
