On Wed, Aug 24, 2011 at 6:50 PM, Alan D. Cabrera <l...@toolazydogs.com> wrote: > > On Aug 24, 2011, at 6:10 AM, Julien Vermillard wrote: > >> On Mon, Aug 22, 2011 at 12:17 AM, Emmanuel Lecharny <elecha...@gmail.com> >> 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 > > +1 > >> 2 : dynamic logging filter is dropped too, we will provide another >> facility for activating logging on incoming/outgoing events > > Not sure that this needs to be done out of hand. I think it might provide > some useful features that might be implemented in a different manner. > Something to chat about. > >> 3 : we craft an accumulation/decoding framework using (layered ?) FSM >> for replacing current CodecFilter > > Can you provide more detail on what the "accumulation/decoding framework" > does and how it works?
Replacing the CumulativeDecoder we actualy have: accumulating enougth byte until we can convert them to pojos. Like accumulating bytes until \n\n for decoding a HttpRequest > >> 4 : implements a codec using the new framework for validating the >> design (could be HTTP or LDAP) > > +9999 I think we need to have a suite of protocols that we need to implement. > Using these as a guide for our API design and to help judge our > implementation would be great. This is what I am doing in my sandbox. I have an HTTP implementation undergoing on my PC, but I stopped due to IoFilter issues. > >> 5 : add SSL/TLS at the transport level > > Not sure that I'm following Actualy SSL is a filter and it's really crippled by hacks, Emmanuel things it should better be handled by NioSocketService or something like that. > >> 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 ? > > I regard the characterization of annotations and generics as "soup" as an > aesthetic judgment; these technologies clearly have value. My reply would be > some people like to see their stereo and cable TV cables running along the > baseboard of their family room and others don't. ;) > > > Regards, > Alan > >
