On 8/21/11 11:48 PM, Alan D. Cabrera wrote:
On Aug 21, 2011, at 11:39 AM, Edouard De Oliveira wrote:
But i'm feeling more and more confused by the fsm need : as you said some
management bits in the session can switch on/off some filters why do we want to
complicate the coder 's life using a two state FSM (in the case of multiple
filters it would generate a much more complicated FSM that the coder would
have to describe with code ... better ?) ?
Do you want the fsm to control the flow between filters (state=filter ?) or do
you want your fsm to control if a filter is active ?
There's no reason why one could not have a chain of FSMs. You get the exact
same behavior with less framework code.
The reason why MINA 1 and 2 has a chain is unclear. One possible
explainaition is that MINA was supposed to implement the SEDA
architecture (each filter communicate with the next filter using a
queue, and as this architecture is supposed to spread filters on more
than one computer, then it's easier to implement it using a chain. Well,
that's my perception. One other reason was the lack of vision about the
possible use cases. 6 years in restrospect, I do think that this need
never surfaced...
The more I think about this problem, the more I think that FSM is the
way to go :
- we don't add filters dynamically on a created session
- we *always* know which filter we will call whatever state we are :
it's a protocol we are handling, it's well defined !
- debugging will be easier
- we won't have to use some strange Mutiplexer filter in order to call
one filter or another depending on the message we are dealing with, like
it's currently the case in MINA 2
- coding a protocol will be easier
- we can define @ to declare the FSM, making the developper's life
easier (an idea that needs to be developed...)
Do we all agree on that ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
