mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julien Vermillard <jvermill...@gmail.com>
Subject Re: Re : Re : [MINA 3.0] filter chains
Date Fri, 26 Aug 2011 11:14:44 GMT
On Thu, Aug 25, 2011 at 2:29 PM, Edouard De Oliveira
<doe_wanted@yahoo.fr> wrote:
> On Wed, Aug 24, 2011 at 7:55 PM, Edouard De Oliveira
> <doe_wanted@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 :
>> 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
>>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

I modified the API to remove IoFilterChain. Now you are supposed to
give a list of filter to the service before starting it :

// create the fitler chain for this service
List<IoFilter> filters = new ArrayList<IoFilter>();
filters.add(new LoggingFilter("byte log filter"));
filters.add(new MyCodecFilter());
filters.add(new LoggingFilter("pojo log filter"));



View raw message