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:30:13 GMT
On Fri, Aug 26, 2011 at 1:23 PM, Emmanuel Lecharny <elecharny@gmail.com> wrote:
> 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 :
>
> acceptor.addFilters(
>    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.
>
Ok, I'll change it for varargs

Mime
View raw message