mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <l...@toolazydogs.com>
Subject Re: [MINA 3.0] filter chains
Date Wed, 24 Aug 2011 16:50:20 GMT

On Aug 24, 2011, at 6:10 AM, Julien Vermillard wrote:

> On Mon, Aug 22, 2011 at 12:17 AM, Emmanuel Lecharny <elecharny@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? 

> 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.

> 5 : add SSL/TLS at the transport level

Not sure that I'm following

> 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


Mime
View raw message