mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: Re : Re : [MINA 3.0] filter chains
Date Fri, 26 Aug 2011 11:23:02 GMT
On 8/26/11 1:14 PM, Julien Vermillard wrote:
> 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 :
>>>> 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 @
> 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"));
> filters.add(newMyProtocolLogicFilter());
> acceptor.setFilters(filters);

I would like to have something like :

     new LoggingFilter("byte log filter"),
     new MyCodecFilter(),
     new LoggingFilter("pojo log filter"),
     newMyProtocolLogicFilter() )

which is easy as soon as we have a Acceptor.addFilters( Filter... 
filters ) method. (ellipsis notation is really very comfy)

thoughts ?

Otherwise, I'm fine with your approach.

Emmanuel L├ęcharny

View raw message