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>
  wrote:
>>>>> 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
written
>>>>>>>>
>>>>>>>> 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",
do
>>>>>>> you have a concrete use case in mind for that ?
>>>>>> The above example does, Foo and the link state filter.  I'm sure
that
>>>>>> we've discussed this before.  Another example is a mux/demux situation.
 How
>>>>>> 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...

<theory>
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
or
F --(transition2)-->  H

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

are we on the same page ?

</theory>


-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com


Mime
View raw message