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] Initial thoughts on FilterChain
Date Mon, 14 Dec 2009 02:29:37 GMT

On Dec 13, 2009, at 2:42 AM, Emmanuel LŽcharny wrote:

> Alan D. Cabrera a écrit :
>> On Dec 3, 2009, at 5:28 PM, Ashish wrote:
>>>>>> What about the assertion that new filters only get created to  
>>>>>> simulate a
>>>>>> state machine?
>>>>> Finally, managed to check-in some of the initial thoughts.
>>>>> The transition handler or the computeNext function is still to  
>>>>> be out in.
>>>> Sorry. Not sure how that answers my question other than to detail  
>>>> what
>>>> you've done and what you're about to do.
>>> OOPS! :-(  I think I am getting old
>>> After a discussion we thought that we shall make it possible for
>>> user's to choose the way we want Filter transitions
>>> That's what the transition handler is :-) Default implementation  
>>> shall
>>> be of next Filter in the chain.
>>> User's can plugin their implementations for transition say like a
>>> State Machine implementation.
>>> Since I couldn't take it to logical conclusion, still working on  
>>> it :)
>>> Also my experience with State machines is limited, so will need a
>>> helping hand here (or may be some references :-) )
>> The key thing about state machines is that the states and the  
>> transitions are known and fixed ahead of time.  If this our state  
>> of affairs, and I think that it is, then things are much more  
>> simple and mentally tractable, i.e. there's no ad hoc filter  
>> creation during protocol processing and much of the threading  
>> issues in past entries on this thread disappear.
> Generally speaking, when implementing a protocol, states and  
> transitions are very well known and static, so the SM approach seems  
> adequate.

Agreed, the SM approach should cover all cases; even the logging case  
in your subsequent post.

So with that said, would it not make sense to have a set of fixed  
filter chains w/ each chain representing a state rather than a bucket  
of filters with each filter deciding the next filter to execute?


View raw message