On Wed, Aug 24, 2011 at 7:55 PM, Edouard De Oliveira <doe_wan...@yahoo.fr> wrote: > > > 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 >
>+1 >it's hard for me to figure if it's going to be the solution witout a >more complex example implementation it's far from being an implementation it's just a basic poc that a fsm can be built with @
