De : Emmanuel Lecharny <[email protected]> À : [email protected] 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<[email protected]> 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<[email protected]> >>>>>>> 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 ? -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
