On Mon, Aug 22, 2011 at 12:17 AM, Emmanuel Lecharny <[email protected]> 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... > > 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 ? >
If we agree, what we have to do : 1 : we drop the concept of dynamic chains, it's nearly what we have in MINA 3.0 branch 2 : dynamic logging filter is dropped too, we will provide another facility for activating logging on incoming/outgoing events 3 : we craft an accumulation/decoding framework using (layered ?) FSM for replacing current CodecFilter 4 : implements a codec using the new framework for validating the design (could be HTTP or LDAP) 5 : add SSL/TLS at the transport level I can work on 1 & 2 even perhaps on 4 but for 3 I no fan of annotation & generic soup. I'm perhaps a too low level guy for that ;) Someone ? Julien
