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.
