mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: [MINA 3.0] filter chains
Date Fri, 26 Aug 2011 15:12:31 GMT
On 8/26/11 4:55 PM, Alan D. Cabrera wrote:
> On Aug 26, 2011, at 7:47 AM, Emmanuel Lecharny wrote:
>> On 8/26/11 4:28 PM, Alan D. Cabrera wrote:
>>> On Aug 26, 2011, at 7:12 AM, Julien Vermillard wrote:
>>>> On Fri, Aug 26, 2011 at 4:07 PM, Emmanuel Lecharny<elecharny@gmail.com>
>>>>> On 8/26/11 3:44 PM, Alan D. Cabrera wrote:
>>>>>> On Aug 26, 2011, at 6:40 AM, Julien Vermillard wrote:
>>>>>>> On Fri, Aug 26, 2011 at 3:24 PM, Alan D. Cabrera<list@toolazydogs.com>
>>>>>>>   wrote:
>>>>>>>> On Aug 26, 2011, at 4:14 AM, Julien Vermillard wrote:
>>>>>>>>> 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(...);
>>>>>>>> How do we make chains where two filters feed into one or
one filter
>>>>>>>> feeds two filters?  If you look in my sandbox we can accommodate
this via:
>>>>>>>> static import a.m.util.Util. linkParentWithChild; // to be
>>>>>>>> IoFilter foo = new FooFilter();
>>>>>>>> LinkStateFilter link = new LinkStateFilter();
>>>>>>>> IoFilter checksum = new ChecksumFilter();
>>>>>>>> IoFilter log = new LogFilter();
>>>>>>>> link.addLinkStateListener(foo);
>>>>>>>> linkParentWithChild(foo, checksum);
>>>>>>>> linkParentWithChild(link, checksum);
>>>>>>>> linkParentWithChild(checksum, log);
>>>>>>>> acceptor.setFilters(foo);
>>>>>>> About the code in the sandbox :
>>>>>>> http://svn.apache.org/repos/asf/mina/sandbox/adc/ahc/mina3/src/main/java/org/apache/mina/core/IoFilter.java
>>>>>>> I see no IoFilter.addLinkStateListener(..) method, am I looking
at the
>>>>>>> right place ?
>>>>>> Oops, it was meant to just be a sketch.  :)
>>>>>>> About the "filters feed into one or one filter feeds two filters",
>>>>>>> you have a concrete use case in mind for that ?
>>>>>> The above example does, Foo and the link state filter.  I'm sure
>>>>>> we've discussed this before.  Another example is a mux/demux situation.
>>>>>> would all of this fit into the grand scheme of things?
>>>>> Yeah, it really should be a graph of filters, not a list of filters.
>>>> Well if it's just for demuxing I proposed few mails ago this solution
>>>> : http://s.apache.org/A9W
>>> I think we need to make graphing a 1st class citizen and not buried inside another
filter class.
>> I do agree. The proposed solution on http://s.apache.org/A9W is what we currently
have, and it's tedious to manage.
>> It would be way better to be able to let the controler call the next filter based
on an evaluation method based on the current state.
>> Now, the question is : how do the controller knows which filter to call next ? It
must have the current state, and it must be able to make the connection.
>> For instance, let's say that from filter F we can switch to either filter G or filter
H, depending on the state we transit to in F.
>> F --(state1)-->  G
>> or
>> F --(state2)-->  H
>> That means the controller has a map { (F, state1, G), (F, state2, H)} somewhere.
State should be passed to the controller too :
>> ...
>> controller.nextFilter( newState );
>> ...
>> Pretty theorical at this point... I'm sorry not to have a lot of time to code this,
I do realize that for you guys implementing ideas it's a PITA...
> I was thinking of a simple DAG some, or all, of the nodes can be FSMs.
> ->  [FSM1] ->  [Filter] ->  [FSM2] ->  [Filter]
> Inside the FSM there could be chains, but there would be one chain per state.
Not sure I grok what you say here. There is more than one state, and 
from each state, you may have more than one transition.

Maybe it's just a problem of vocabulary...

In a FSM, you transit from Si to Sj, following a transition Ta, which 
depends on a context. You may also transit to a state Sk, following a 
different transition Tb, if the context is different.

Selection the transition to follow is all about knowing what's the 
context is, and in my sample, this was what I call the 'state', which 
was most certainly an error, as it's clearly a transition. I should have 
wrote :

F --(transition1)-->  G
F --(transition2)-->  H

where F, G, H are filters (ore "states")

are we on the same page ?


Emmanuel L├ęcharny

View raw message