On Dec 14, 2009, at 1:19 AM, Emmanuel Lecharny wrote:
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).
Thanks Emmanuel, I think this accurately reflects my thinking. I
think that the crux of our discussion lies on the point of whether
filters need to be injected in an ad hoc fashion. If so then SM is
probably not the way to go.
Regards,
Alan
