On Dec 13, 2009, at 2:42 AM, Emmanuel Lcharny wrote:
Alan D. Cabrera a écrit :
On Dec 3, 2009, at 5:28 PM, Ashish wrote:
What about the assertion that new filters only get created to
simulate a
state machine?
Finally, managed to check-in some of the initial thoughts.
The transition handler or the computeNext function is still to
be out in.
Sorry. Not sure how that answers my question other than to detail
what
you've done and what you're about to do.
OOPS! :-( I think I am getting old
After a discussion we thought that we shall make it possible for
user's to choose the way we want Filter transitions
That's what the transition handler is :-) Default implementation
shall
be of next Filter in the chain.
User's can plugin their implementations for transition say like a
State Machine implementation.
Since I couldn't take it to logical conclusion, still working on
it :)
Also my experience with State machines is limited, so will need a
helping hand here (or may be some references :-) )
The key thing about state machines is that the states and the
transitions are known and fixed ahead of time. If this our state
of affairs, and I think that it is, then things are much more
simple and mentally tractable, i.e. there's no ad hoc filter
creation during protocol processing and much of the threading
issues in past entries on this thread disappear.
Generally speaking, when implementing a protocol, states and
transitions are very well known and static, so the SM approach seems
adequate.
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?
Regards,
Alan
