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] filter chains
Date Fri, 26 Aug 2011 16:09:14 GMT

On Aug 26, 2011, at 9:02 AM, Edouard De Oliveira wrote:

> De : Emmanuel Lecharny <elecharny@gmail.com>
> 
> À : dev@mina.apache.org
> Envoyé le : Vendredi 26 Août 2011 17h12
> Objet : Re: [MINA 3.0] filter chains
> 
> 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>
> 
> 
> The theory sounds ok but it also seems that Alan has something much more (too ?) complex
in mind 
> for those who wandered what a DAG is i think it's this http://en.wikipedia.org/wiki/Directed_acyclic_graph
do you confirm alan ?

Yes, this is the definition of a DAG but I am using it to precisely state the characteristics
of the graph.  Simply put, no circularities.

A tree is a DAG.  MUX/DEMUX is a DAG.

As I mentioned, it's a simple straightforward concept that every programmer should know. 
The benefit is that it dramatically keeps things simpler by removing circularities.


Regards,
Alan




Mime
View raw message