On Thu, Aug 25, 2011 at 2:29 PM, Edouard De Oliveira
<[email protected]> wrote:
> On Wed, Aug 24, 2011 at 7:55 PM, Edouard De Oliveira
>
> <[email protected]> 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);
acceptor.bind(...);
