Alan D. Cabrera a écrit :
On Dec 13, 2009, at 2:42 AM, Emmanuel LŽcharny wrote:
<snip/>
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?
Not necessarily, for three reasons :
1) if the chain is fixed at startup, you can't anymore inject a
LoggingFilter when the server is running. You can only activate or
desactivate it. Not that it's realy a big issue, but it may help in some
case (that also mean we have a way to control the execution. JMX ?)
2) Most important, if we don't have a clue about which is the next
filter in the chain, that leads to problem when debugging, as you can't
know which filter will be called. Ennoying
3) Last, not least, we want to be able to call the next filter in the
middle of a processing :
messageReceived() {
do blah();
if ( condition ) {
do anotherBlah();
call Next filter();
} else {
do yetAnotherBlah();
call nextFilter();
}
do endingBlah();
}
Not sure this is possible in another way than with those computed
nextFilter() inside the filters.
(well, t's always possible to express this with more transitions and
states, but t would be more complicated to write filters then...)
Regards,
Alan
--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com