Ashish a écrit :
Agreed, the SM approach should cover all cases; even the logging case in
your subsequent post.
So with that said, would it not make sense to have a set of fixed filter
chains w/ each chain representing a state rather than a bucket of filters
with each filter deciding the next filter to execute?
Sorry , but I am confused :-(
can you help me understand how the Filter chains as a state would work?
Here is a simple Chain. The one with * can be dynamically
added/removed. Logging filter could be added at multiple places
Acceptor -> BlackList Filter -> Logging Filter* -> Throughput Filter*
-> Executor Filter -> Codec -> Logging Filter *
->IoHandler
Now how would the suggested approach work??
If I understand Alan, the idea is that the transitions are managed by
the SM handler. As state are static, transitions just depend on th
context, so an external engine can call the next state considering the
current context. In this case, states don't have to know which is the
next state, because it's computed in the SM engine.
It's a typical SM approach, but I'm not sure that it's convenient for us
(see my other reply).
--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com
