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