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... With the growing of the base code it's easier just by looking at what exists to find some use case one would not have though of at this time >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 ! +1 : it's just that it will require much more preliminary toughts to start coding a server -> that's our good practices promoting thing >- debugging will be easier i won't be so categorical about this as whatever graph type you use to describe your 'chain' it will still be session/data dependent >- 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 not so strange as it is a well known design pattern (Command Pattern) >- coding a protocol will be easier we have to make basic servers easier (or as easy as before) too >- we can define @ to declare the FSM, making the developper's life easier (an >idea that needs to be developed...) >i was also planning on some @ (like @unique to limit the presence of a filter >in the chain or some more generic one that would provide the name and the >unicity of the filter for Mina 2 obviously) >for mina 3 i indeed was wondering if somehow we could use @ to prevent bloated >FSM declaration code and found this interesting article >which could be a good >base to start with : >http://weblogs.java.net/blog/carcassi/archive/2007/02/finite_state_ma_1.html You can find a fast hack at the following pastebin url which shows how i changed the original code of the article to add data dependent transitions : http://pastebin.com/CjXjJ2Q1 >Do we all agree on that ? >There's lot of momentum on this solution so it should be given at least a try >obviously
