[MINA 3.0] dependency against google guava
Hi ! I would like to use google guava for core MINA functionalities. Possible usages : Immutable List : http://guava-libraries.googlecode.com/svn/tags/release09/javadoc/com/google/common/collect/ImmutableList.html convenient for storing filter list in an immutable fashion. Listenable futures : http://guava-libraries.googlecode.com/svn/tags/release09/javadoc/com/google/common/util/concurrent/ListenableFuture.html http://guava-libraries.googlecode.com/svn/tags/release09/javadoc/com/google/common/util/concurrent/AbstractListenableFuture.html http://guava-libraries.googlecode.com/svn/tags/release09/javadoc/index.html?com/google/common/util/concurrent/Futures.html Convenient InetAddress methods avoiding DNS requests : http://guava-libraries.googlecode.com/svn/tags/release09/javadoc/index.html?com/google/common/net/InetAddresses.html The HashMap tools are very cool and help you to keep your code concise : ex : in place of MapK,V myMap = new HashMapK,V(); you can write : MapK,V myMap = Maps.newHashMap(); WDYT ?
Re: [MINA 3.0] dependency against google guava
On Fri, Aug 26, 2011 at 12:57 PM, Julien Vermillard jvermill...@gmail.com wrote: Hi ! I would like to use google guava for core MINA functionalities. Possible usages : Immutable List : http://guava-libraries.googlecode.com/svn/tags/release09/javadoc/com/google/common/collect/ImmutableList.html convenient for storing filter list in an immutable fashion. Listenable futures : http://guava-libraries.googlecode.com/svn/tags/release09/javadoc/com/google/common/util/concurrent/ListenableFuture.html http://guava-libraries.googlecode.com/svn/tags/release09/javadoc/com/google/common/util/concurrent/AbstractListenableFuture.html http://guava-libraries.googlecode.com/svn/tags/release09/javadoc/index.html?com/google/common/util/concurrent/Futures.html Convenient InetAddress methods avoiding DNS requests : http://guava-libraries.googlecode.com/svn/tags/release09/javadoc/index.html?com/google/common/net/InetAddresses.html The HashMap tools are very cool and help you to keep your code concise : ex : in place of MapK,V myMap = new HashMapK,V(); you can write : MapK,V myMap = Maps.newHashMap(); WDYT ? I forgot the license : ASL2
Re: [MINA 3.0] dependency against google guava
+1 I like a lot of functionalities provided by GUava and the ones listed are real good ones :) On Fri, Aug 26, 2011 at 4:28 PM, Julien Vermillard jvermill...@gmail.comwrote: On Fri, Aug 26, 2011 at 12:57 PM, Julien Vermillard jvermill...@gmail.com wrote: Hi ! I would like to use google guava for core MINA functionalities. Possible usages : Immutable List : http://guava-libraries.googlecode.com/svn/tags/release09/javadoc/com/google/common/collect/ImmutableList.html convenient for storing filter list in an immutable fashion. Listenable futures : http://guava-libraries.googlecode.com/svn/tags/release09/javadoc/com/google/common/util/concurrent/ListenableFuture.html http://guava-libraries.googlecode.com/svn/tags/release09/javadoc/com/google/common/util/concurrent/AbstractListenableFuture.html http://guava-libraries.googlecode.com/svn/tags/release09/javadoc/index.html?com/google/common/util/concurrent/Futures.html Convenient InetAddress methods avoiding DNS requests : http://guava-libraries.googlecode.com/svn/tags/release09/javadoc/index.html?com/google/common/net/InetAddresses.html The HashMap tools are very cool and help you to keep your code concise : ex : in place of MapK,V myMap = new HashMapK,V(); you can write : MapK,V myMap = Maps.newHashMap(); WDYT ? I forgot the license : ASL2
Re: Re : Re : [MINA 3.0] filter chains
On Thu, Aug 25, 2011 at 2:29 PM, Edouard De Oliveira doe_wan...@yahoo.fr wrote: On Wed, Aug 24, 2011 at 7:55 PM, Edouard De Oliveira doe_wan...@yahoo.fr wrote: On 8/21/11 11:48 PM, Alan D. Cabrera wrote: On Aug 21, 2011, at 11:39 AM, Edouard De Oliveira wrote: But i'm feeling more and more confused by the fsm need : as you said some management bits in the session can switch on/off some filters why do we want to complicate the coder 's life using a two state FSM (in the case of multiple filters it would generate a much more complicated FSM that the coder would have to describe with code ... better ?) ? Do you want the fsm to control the flow between filters (state=filter ?) or do you want your fsm to control if a filter is active ? There's no reason why one could not have a chain of FSMs. You get the exact same behavior with less framework code. The reason why MINA 1 and 2 has a chain is unclear. One possible explainaition is that MINA was supposed to implement the SEDA architecture (each filter communicate with the next filter using a queue, and as this architecture is supposed to spread filters on more than one computer, then it's easier to implement it using a chain. Well, that's my perception. One other reason was the lack of vision about the possible use cases. 6 years in restrospect, I do think that this need never surfaced... With the growing of the base code it's easier just by looking at what exists to find some use case one would not have though of at this time The more I think about this problem, the more I think that FSM is the way to go : - we don't add filters dynamically on a created session - we *always* know which filter we will call whatever state we are : it's a protocol we are handling, it's well defined ! +1 : it's just that it will require much more preliminary toughts to start coding a server - that's our good practices promoting thing - debugging will be easier i won't be so categorical about this as whatever graph type you use to describe your 'chain' it will still be session/data dependent - we won't have to use some strange Mutiplexer filter in order to call one filter or another depending on the message we are dealing with, like it's currently the case in MINA 2 not so strange as it is a well known design pattern (Command Pattern) - coding a protocol will be easier we have to make basic servers easier (or as easy as before) too - we can define @ to declare the FSM, making the developper's life easier (an idea that needs to be developed...) i was also planning on some @ (like @unique to limit the presence of a filter in the chain or some more generic one that would provide the name and the unicity of the filter for Mina 2 obviously) for mina 3 i indeed was wondering if somehow we could use @ to prevent bloated FSM declaration code and found this interesting article which could be a good base to start with : http://weblogs.java.net/blog/carcassi/archive/2007/02/finite_state_ma_1.html You can find a fast hack at the following pastebin url which shows how i changed the original code of the article to add data dependent transitions : http://pastebin.com/CjXjJ2Q1 Do we all agree on that ? There's lot of momentum on this solution so it should be given at least a try obviously +1 it's hard for me to figure if it's going to be the solution witout a more complex example implementation it's far from being an implementation it's just a basic poc that a fsm can be built with @ 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 ListIoFilter filters = new ArrayListIoFilter(); 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(...);
Re: [MINA 3.0] dependency against google guava
On 8/26/11 12:57 PM, Julien Vermillard wrote: Hi ! I would like to use google guava for core MINA functionalities. Possible usages : Immutable List : http://guava-libraries.googlecode.com/svn/tags/release09/javadoc/com/google/common/collect/ImmutableList.html convenient for storing filter list in an immutable fashion. You can make a list immutable by using Collections.unmodifiable( List ). Listenable futures : http://guava-libraries.googlecode.com/svn/tags/release09/javadoc/com/google/common/util/concurrent/ListenableFuture.html http://guava-libraries.googlecode.com/svn/tags/release09/javadoc/com/google/common/util/concurrent/AbstractListenableFuture.html http://guava-libraries.googlecode.com/svn/tags/release09/javadoc/index.html?com/google/common/util/concurrent/Futures.html Convenient InetAddress methods avoiding DNS requests : http://guava-libraries.googlecode.com/svn/tags/release09/javadoc/index.html?com/google/common/net/InetAddresses.html A soon as it brings some value, I have no problem with using a external lib. However, if we can get the same result without dependency on another external lib, that would be better, IMO. For instance, ListenableFuture is already available in ActiveMQ (http://activemq.apache.org/apollo/documentation/api/apollo-util/org/apache/activemq/apollo/util/ListenableFuture.html). Copyong the code from there inside MINA would be a possibility. The HashMap tools are very cool and help you to keep your code concise : ex : in place of MapK,V myMap = new HashMapK,V(); you can write : MapK,V myMap = Maps.newHashMap(); Not really convinced aboyt the gain, here. Bottom line : adding a new dependency is an annoyance, to me. We have to add the dependency to MINA, forcing our users to load it. Plus if we decide to make MINA OSGi compliant, we will have to encapsulate Guava into a separate project, maiking it an OSGi bundle. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: Re : Re : [MINA 3.0] filter chains
On 8/26/11 1:14 PM, Julien Vermillard wrote: On Thu, Aug 25, 2011 at 2:29 PM, Edouard De Oliveira doe_wan...@yahoo.fr wrote: On Wed, Aug 24, 2011 at 7:55 PM, Edouard De Oliveira doe_wan...@yahoo.fr wrote: On 8/21/11 11:48 PM, Alan D. Cabrera wrote: On Aug 21, 2011, at 11:39 AM, Edouard De Oliveira wrote: But i'm feeling more and more confused by the fsm need : as you said some management bits in the session can switch on/off some filters why do we want to complicate the coder 's life using a two state FSM (in the case of multiple filters it would generate a much more complicated FSM that the coder would have to describe with code ... better ?) ? Do you want the fsm to control the flow between filters (state=filter ?) or do you want your fsm to control if a filter is active ? There's no reason why one could not have a chain of FSMs. You get the exact same behavior with less framework code. The reason why MINA 1 and 2 has a chain is unclear. One possible explainaition is that MINA was supposed to implement the SEDAarchitecture (each filter communicate with the next filter using a queue, and as this architecture is supposed to spread filters on more thanone computer, then it's easier to implement it using a chain. Well, that's my perception. One other reason was the lack of vision about thepossible use cases. 6 years in restrospect, I do think that this need never surfaced... With the growing of the base code it's easier just by looking at what exists to find some use case one would not have though of at this time The more I think about this problem, the more I think that FSM is the way to go : - we don't add filters dynamically on a created session - we *always* know which filter we will call whatever state we are : it's a protocol we are handling, it's well defined ! +1 : it's just that it will require much more preliminary toughts to start coding a server - that's our good practices promoting thing - debugging will be easier i won't be so categorical about this as whatever graph type you use to describe your 'chain' it will still be session/data dependent - we won't have to use some strange Mutiplexer filter in order to call one filter or another depending on the message we are dealing with, likeit's currently the case in MINA 2 not so strange as it is a well known design pattern (Command Pattern) - coding a protocol will be easier we have to make basic servers easier (or as easy as before) too - we can define @ to declare the FSM, making the developper's life easier (an idea that needs to be developed...) i was also planning on some @ (like @unique to limit the presence of a filter in the chain or some more generic one that would provide the name and the unicity of the filter for Mina 2 obviously) for mina 3 i indeed was wondering if somehow we could use @ to prevent bloated FSM declaration code and found this interesting articlewhich could be a good base to start with : http://weblogs.java.net/blog/carcassi/archive/2007/02/finite_state_ma_1.html You can find a fast hack at the following pastebin url which shows how i changed the original code of the article to add data dependent transitions : http://pastebin.com/CjXjJ2Q1 Do we all agree on that ? There's lot of momentum on this solution so it should be given at least a try obviously +1 it's hard for me to figure if it's going to be the solution witout a more complex example implementation it's far from being an implementation it's just a basic poc that a fsm can be built with @ 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 ListIoFilter filters = new ArrayListIoFilter(); filters.add(new LoggingFilter(byte log filter)); filters.add(new MyCodecFilter()); filters.add(new LoggingFilter(pojo log filter)); filters.add(newMyProtocolLogicFilter()); acceptor.setFilters(filters); I would like to have something like : acceptor.addFilters( new LoggingFilter(byte log filter), new MyCodecFilter(), new LoggingFilter(pojo log filter), newMyProtocolLogicFilter() ) which is easy as soon as we have a Acceptor.addFilters( Filter... filters ) method. (ellipsis notation is really very comfy) thoughts ? Otherwise, I'm fine with your approach. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: Re : Re : [MINA 3.0] filter chains
On Fri, Aug 26, 2011 at 1:23 PM, Emmanuel Lecharny elecha...@gmail.com wrote: On 8/26/11 1:14 PM, Julien Vermillard wrote: On Thu, Aug 25, 2011 at 2:29 PM, Edouard De Oliveira doe_wan...@yahoo.fr wrote: On Wed, Aug 24, 2011 at 7:55 PM, Edouard De Oliveira doe_wan...@yahoo.fr wrote: On 8/21/11 11:48 PM, Alan D. Cabrera wrote: On Aug 21, 2011, at 11:39 AM, Edouard De Oliveira wrote: But i'm feeling more and more confused by the fsm need : as you said some management bits in the session can switch on/off some filters why do we want to complicate the coder 's life using a two state FSM (in the case of multiple filters it would generate a much more complicated FSM that the coder would have to describe with code ... better ?) ? Do you want the fsm to control the flow between filters (state=filter ?) or do you want your fsm to control if a filter is active ? There's no reason why one could not have a chain of FSMs. You get the exact same behavior with less framework code. The reason why MINA 1 and 2 has a chain is unclear. One possible explainaition is that MINA was supposed to implement the SEDAarchitecture (each filter communicate with the next filter using a queue, and as this architecture is supposed to spread filters on more thanone computer, then it's easier to implement it using a chain. Well, that's my perception. One other reason was the lack of vision about thepossible use cases. 6 years in restrospect, I do think that this need never surfaced... With the growing of the base code it's easier just by looking at what exists to find some use case one would not have though of at this time The more I think about this problem, the more I think that FSM is the way to go : - we don't add filters dynamically on a created session - we *always* know which filter we will call whatever state we are : it's a protocol we are handling, it's well defined ! +1 : it's just that it will require much more preliminary toughts to start coding a server - that's our good practices promoting thing - debugging will be easier i won't be so categorical about this as whatever graph type you use to describe your 'chain' it will still be session/data dependent - we won't have to use some strange Mutiplexer filter in order to call one filter or another depending on the message we are dealing with, likeit's currently the case in MINA 2 not so strange as it is a well known design pattern (Command Pattern) - coding a protocol will be easier we have to make basic servers easier (or as easy as before) too - we can define @ to declare the FSM, making the developper's life easier (an idea that needs to be developed...) i was also planning on some @ (like @unique to limit the presence of a filter in the chain or some more generic one that would provide the name and the unicity of the filter for Mina 2 obviously) for mina 3 i indeed was wondering if somehow we could use @ to prevent bloated FSM declaration code and found this interesting articlewhich could be a good base to start with : http://weblogs.java.net/blog/carcassi/archive/2007/02/finite_state_ma_1.html You can find a fast hack at the following pastebin url which shows how i changed the original code of the article to add data dependent transitions : http://pastebin.com/CjXjJ2Q1 Do we all agree on that ? There's lot of momentum on this solution so it should be given at least a try obviously +1 it's hard for me to figure if it's going to be the solution witout a more complex example implementation it's far from being an implementation it's just a basic poc that a fsm can be built with @ 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 ListIoFilter filters = new ArrayListIoFilter(); filters.add(new LoggingFilter(byte log filter)); filters.add(new MyCodecFilter()); filters.add(new LoggingFilter(pojo log filter)); filters.add(newMyProtocolLogicFilter()); acceptor.setFilters(filters); I would like to have something like : acceptor.addFilters( new LoggingFilter(byte log filter), new MyCodecFilter(), new LoggingFilter(pojo log filter), newMyProtocolLogicFilter() ) which is easy as soon as we have a Acceptor.addFilters( Filter... filters ) method. (ellipsis notation is really very comfy) thoughts ? Otherwise, I'm fine with your approach. Ok, I'll change it for varargs
Re: [MINA 3.0] dependency against google guava
On Aug 26, 2011, at 4:20 AM, Emmanuel Lecharny wrote: On 8/26/11 12:57 PM, Julien Vermillard wrote: Hi ! I would like to use google guava for core MINA functionalities. Possible usages : Immutable List : http://guava-libraries.googlecode.com/svn/tags/release09/javadoc/com/google/common/collect/ImmutableList.html convenient for storing filter list in an immutable fashion. You can make a list immutable by using Collections.unmodifiable( List ). I'm thinking the same thing. Listenable futures : http://guava-libraries.googlecode.com/svn/tags/release09/javadoc/com/google/common/util/concurrent/ListenableFuture.html http://guava-libraries.googlecode.com/svn/tags/release09/javadoc/com/google/common/util/concurrent/AbstractListenableFuture.html http://guava-libraries.googlecode.com/svn/tags/release09/javadoc/index.html?com/google/common/util/concurrent/Futures.html Convenient InetAddress methods avoiding DNS requests : http://guava-libraries.googlecode.com/svn/tags/release09/javadoc/index.html?com/google/common/net/InetAddresses.html A soon as it brings some value, I have no problem with using a external lib. However, if we can get the same result without dependency on another external lib, that would be better, IMO. For instance, ListenableFuture is already available in ActiveMQ (http://activemq.apache.org/apollo/documentation/api/apollo-util/org/apache/activemq/apollo/util/ListenableFuture.html). Copyong the code from there inside MINA would be a possibility. We could copy it but I have already written the same stuff and checked it in. Happy to get rid of it if we find more extensive use for Guava. The HashMap tools are very cool and help you to keep your code concise : ex : in place of MapK,V myMap = new HashMapK,V(); you can write : MapK,V myMap = Maps.newHashMap(); Not really convinced aboyt the gain, here. Ditto. Bottom line : adding a new dependency is an annoyance, to me. We have to add the dependency to MINA, forcing our users to load it. Plus if we decide to make MINA OSGi compliant, we will have to encapsulate Guava into a separate project, maiking it an OSGi bundle. Ditto. Regards, Alan
Re: [MINA 3.0] filter chains
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 ListIoFilter filters = new ArrayListIoFilter(); 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(); IoFilter 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);
I know that I'm being fussy
But shouldn't branches/2.0.5 be named branches/2.0? Regards, Alan
Re: [MINA 3.0] filter chains
On Fri, Aug 26, 2011 at 3:24 PM, Alan D. Cabrera l...@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 ListIoFilter filters = new ArrayListIoFilter(); 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(); IoFilter 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 ? About the filters feed into one or one filter feeds two filters, do you have a concrete use case in mind for that ?
Re: [MINA 3.0] filter chains
On Aug 26, 2011, at 6:40 AM, Julien Vermillard wrote: On Fri, Aug 26, 2011 at 3:24 PM, Alan D. Cabrera l...@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 ListIoFilter filters = new ArrayListIoFilter(); 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? Regards, Alan
Re: [MINA 3.0] filter chains
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. Cabreral...@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 ListIoFilter filters = new ArrayListIoFilter(); 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. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: I know that I'm being fussy
On 8/26/11 3:31 PM, Alan D. Cabrera wrote: But shouldn't branches/2.0.5 be named branches/2.0? Yes. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: [MINA 3.0] filter chains
On Fri, Aug 26, 2011 at 4:07 PM, Emmanuel Lecharny elecha...@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. Cabreral...@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 ListIoFilter filters = new ArrayListIoFilter(); 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 Julien
Re : [MINA 3.0] filter chains
On Aug 26, 2011, at 6:40 AM, Julien Vermillard wrote: On Fri, Aug 26, 2011 at 3:24 PM, Alan D. Cabrera l...@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 ListIoFilter filters = new ArrayListIoFilter(); 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? Regards, Alan On my side, besides the @ fsm declaration api (which may be impossible to use as i think it fixes the position of a filter in the chain which is not universal) i wrote a simple api i'd like your thoughts on (using the type of syntax used in hibernate criteria) : FSMState init = getInitialState(); FSMState b = init.linksTo(FSMStateB.class); b.linksTo(FSMStateZ.class); FSMState d = b.linksTo(FSMStateC.class).linksTo(FSMStateD.class); d.linksTo(FSMStateE.class); d.linksTo(FSMStateF.class); which represents obviously : INIT - B - Z |- C - D - E |- F wdyt ?
Re: [MINA 3.0] filter chains
On Aug 26, 2011, at 7:12 AM, Julien Vermillard wrote: On Fri, Aug 26, 2011 at 4:07 PM, Emmanuel Lecharny elecha...@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. Cabreral...@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 ListIoFilter filters = new ArrayListIoFilter(); 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. Regards, Alan
Re: [MINA 3.0] filter chains
On Fri, Aug 26, 2011 at 4:28 PM, Alan D. Cabrera l...@toolazydogs.com wrote: On Aug 26, 2011, at 7:12 AM, Julien Vermillard wrote: On Fri, Aug 26, 2011 at 4:07 PM, Emmanuel Lecharny elecha...@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. Cabreral...@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 ListIoFilter filters = new ArrayListIoFilter(); 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 think we need to avoid complex feature like graph. IMHO server in MINA is a codec and an handler 90% of the time. Someone have a use case which could use filter graph with MINA ?
Re: [MINA 3.0] filter chains
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 Lecharnyelecha...@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. Cabreral...@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
ListIoFilter filters = new ArrayListIoFilter();
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...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA 3.0] filter chains
On 8/26/11 4:41 PM, Julien Vermillard wrote: On Fri, Aug 26, 2011 at 4:28 PM, Alan D. Cabreral...@toolazydogs.com wrote: On Aug 26, 2011, at 7:12 AM, Julien Vermillard wrote: On Fri, Aug 26, 2011 at 4:07 PM, Emmanuel Lecharnyelecha...@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. Cabreral...@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 ListIoFilterfilters = new ArrayListIoFilter(); 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 think we need to avoid complex feature like graph. IMHO server in MINA is a codec and an handler 90% of the time. Someone have a use case which could use filter graph with MINA ? yes. We use it for LDAP... And we have had some users asking how to manage a decoder for multiple kind of messages. This is not something we want just because it's beautiful. Now, what about having a controller hidding the internal structure, so that we can switch to a graph later ? IMO, we should not expose the inner data structure, be it a list or a graph. It's the controller's business to deal with that. However, we must provide the current state to the controller, it's not enough to provide the current filter. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: [MINA 3.0] filter chains
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 Lecharnyelecha...@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. Cabreral...@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
ListIoFilter filters = new ArrayListIoFilter();
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.
The message would run its course through the chain and then the next state
would be set. Otherwise things become intractable.
Regards,
Alan
Re: [MINA 3.0] filter chains
On Aug 26, 2011, at 7:54 AM, Emmanuel Lecharny wrote: On 8/26/11 4:41 PM, Julien Vermillard wrote: On Fri, Aug 26, 2011 at 4:28 PM, Alan D. Cabreral...@toolazydogs.com wrote: On Aug 26, 2011, at 7:12 AM, Julien Vermillard wrote: On Fri, Aug 26, 2011 at 4:07 PM, Emmanuel Lecharnyelecha...@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. Cabreral...@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 ListIoFilterfilters = new ArrayListIoFilter(); 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 think we need to avoid complex feature like graph. IMHO server in MINA is a codec and an handler 90% of the time. Someone have a use case which could use filter graph with MINA ? yes. We use it for LDAP... And we have had some users asking how to manage a decoder for multiple kind of messages. This is not something we want just because it's beautiful. Now, what about having a controller hidding the internal structure, so that we can switch to a graph later ? IMO, we should not expose the inner data structure, be it a list or a graph. It's the controller's business to deal with that. However, we must provide the current state to the controller, it's not enough to provide the current filter. Look at how things are set up in my sandbox. The parents and children can have any cardinality, even zero. The controller should be able to automatically handle all of that. Regards, Alan
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 Lecharnyelecha...@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. Cabreral...@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
ListIoFilterfilters = new ArrayListIoFilter();
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
Re : [MINA 3.0] filter chains
De : Emmanuel Lecharny elecha...@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
Lecharnyelecha...@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. Cabreral...@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
ListIoFilter filters = new ArrayListIoFilter();
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
Re: [MINA 3.0] filter chains
On Aug 26, 2011, at 8:12 AM, Emmanuel Lecharny wrote:
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 Lecharnyelecha...@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. Cabreral...@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
ListIoFilterfilters = new ArrayListIoFilter();
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
Not at all. :)
Are F, G, H filters inside the FSM or are they external to the FSM?
Regards,
Alan
Re: [MINA 3.0] filter chains
On Aug 26, 2011, at 9:02 AM, Edouard De Oliveira wrote:
De : Emmanuel Lecharny elecha...@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 Lecharnyelecha...@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. Cabreral...@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
ListIoFilterfilters = new ArrayListIoFilter();
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
Re: Re : [MINA 3.0] filter chains
On 8/26/11 6:02 PM, Edouard De Oliveira wrote: De : Emmanuel Lecharnyelecha...@gmail.com 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 ? DAG is just a restricted form of a FSM. It just forbid a loop, which is exactly what we need in our case (why would we cycle on a filter we already went through ?) -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: [MINA 3.0] filter chains
On 8/26/11 6:03 PM, Alan D. Cabrera wrote:
On Aug 26, 2011, at 8:12 AM, Emmanuel Lecharny wrote:
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 Lecharnyelecha...@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. Cabreral...@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
ListIoFilter filters = new ArrayListIoFilter();
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
Not at all. :)
Are F, G, H filters inside the FSM or are they external to the FSM?
They are filters in the FSM.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA 3.0] dependency against google guava
On Fri, Aug 26, 2011 at 2:20 PM, Emmanuel Lecharny elecha...@gmail.comwrote: On 8/26/11 12:57 PM, Julien Vermillard wrote: Hi ! I would like to use google guava for core MINA functionalities. Possible usages : Immutable List : http://guava-libraries.**googlecode.com/svn/tags/** release09/javadoc/com/google/**common/collect/ImmutableList.**htmlhttp://guava-libraries.googlecode.com/svn/tags/release09/javadoc/com/google/common/collect/ImmutableList.html convenient for storing filter list in an immutable fashion. You can make a list immutable by using Collections.unmodifiable( List ). Listenable futures : http://guava-libraries.**googlecode.com/svn/tags/** release09/javadoc/com/google/**common/util/concurrent/** ListenableFuture.htmlhttp://guava-libraries.googlecode.com/svn/tags/release09/javadoc/com/google/common/util/concurrent/ListenableFuture.html http://guava-libraries.**googlecode.com/svn/tags/** release09/javadoc/com/google/**common/util/concurrent/** AbstractListenableFuture.htmlhttp://guava-libraries.googlecode.com/svn/tags/release09/javadoc/com/google/common/util/concurrent/AbstractListenableFuture.html http://guava-libraries.**googlecode.com/svn/tags/** release09/javadoc/index.html?**com/google/common/util/** concurrent/Futures.htmlhttp://guava-libraries.googlecode.com/svn/tags/release09/javadoc/index.html?com/google/common/util/concurrent/Futures.html Convenient InetAddress methods avoiding DNS requests : http://guava-libraries.**googlecode.com/svn/tags/** release09/javadoc/index.html?**com/google/common/net/**InetAddresses.htmlhttp://guava-libraries.googlecode.com/svn/tags/release09/javadoc/index.html?com/google/common/net/InetAddresses.html A soon as it brings some value, I have no problem with using a external lib. However, if we can get the same result without dependency on another external lib, that would be better, IMO. Yeah I have to agree with Emmanuel on this one. It will become a PITA but perhaps some shade plugin magic can fix that? For instance, ListenableFuture is already available in ActiveMQ ( http://activemq.apache.org/**apollo/documentation/api/** apollo-util/org/apache/**activemq/apollo/util/**ListenableFuture.htmlhttp://activemq.apache.org/apollo/documentation/api/apollo-util/org/apache/activemq/apollo/util/ListenableFuture.html). Copyong the code from there inside MINA would be a possibility. The HashMap tools are very cool and help you to keep your code concise : ex : in place of MapK,V myMap = new HashMapK,V(); you can write : MapK,V myMap = Maps.newHashMap(); Not really convinced aboyt the gain, here. +1 Bottom line : adding a new dependency is an annoyance, to me. We have to add the dependency to MINA, forcing our users to load it. Plus if we decide to make MINA OSGi compliant, we will have to encapsulate Guava into a separate project, maiking it an OSGi bundle. +1 -- Best Regards, -- Alex
Re: [MINA 3.0] filter chains
On Fri, Aug 26, 2011 at 6:10 PM, Emmanuel Lecharny elecha...@gmail.com wrote:
On 8/26/11 6:03 PM, Alan D. Cabrera wrote:
On Aug 26, 2011, at 8:12 AM, Emmanuel Lecharny wrote:
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
Lecharnyelecha...@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.
Cabreral...@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
ListIoFilter filters = new ArrayListIoFilter();
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
Not at all. :)
Are F, G, H filters inside the FSM or are they external to the FSM?
They are filters in the FSM.
Until your minds are clear about where to go about muxing,FSM and
filters I'll continue low-level implementation of MINA 3.0. The actual
filter chain is enough for me to do protocol implementation and perf
testing the NIO loops.
Julien
Re: [MINA 3.0] filter chains
On Aug 26, 2011, at 9:10 AM, Emmanuel Lecharny wrote:
On 8/26/11 6:03 PM, Alan D. Cabrera wrote:
On Aug 26, 2011, at 8:12 AM, Emmanuel Lecharny wrote:
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 Lecharnyelecha...@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.
Cabreral...@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
ListIoFilter filters = new ArrayListIoFilter();
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
Not at all. :)
Are F, G, H filters inside the FSM or are they external to the FSM?
They are filters in the FSM.
Ok, now I know where you're coming from. For me I have a map of chains
MapState, Chain states = …
State current;
void send(T message)
{
Chain chain = states.get(current);
current = chain.send(message);
}
So the effect is
[outside filter] - [FSM [current chain] ] - [outside filter]
Re: [MINA 3.0] filter chains
On 8/26/11 6:15 PM, Julien Vermillard wrote:
On Fri, Aug 26, 2011 at 6:10 PM, Emmanuel Lecharnyelecha...@gmail.com wrote:
On 8/26/11 6:03 PM, Alan D. Cabrera wrote:
On Aug 26, 2011, at 8:12 AM, Emmanuel Lecharny wrote:
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
Lecharnyelecha...@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.
Cabreral...@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
ListIoFilter filters = new ArrayListIoFilter();
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
Not at all. :)
Are F, G, H filters inside the FSM or are they external to the FSM?
They are filters in the FSM.
Until your minds are clear about where to go about muxing,FSM and
filters I'll continue low-level implementation of MINA 3.0. The actual
filter chain is enough for me to do protocol implementation and perf
testing the NIO loops.
Go ahead. The fact that we are brain-storming about some additional
feature should not stop you to build some good base we can butcher later :)
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA 3.0] filter chains
On Aug 26, 2011, at 9:15 AM, Julien Vermillard wrote:
On Fri, Aug 26, 2011 at 6:10 PM, Emmanuel Lecharny elecha...@gmail.com
wrote:
On 8/26/11 6:03 PM, Alan D. Cabrera wrote:
On Aug 26, 2011, at 8:12 AM, Emmanuel Lecharny wrote:
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
Lecharnyelecha...@gmail.comwrote:
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.
Cabreral...@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
ListIoFilter filters = new ArrayListIoFilter();
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
Not at all. :)
Are F, G, H filters inside the FSM or are they external to the FSM?
They are filters in the FSM.
Until your minds are clear about where to go about muxing,FSM and
filters I'll continue low-level implementation of MINA 3.0. The actual
filter chain is enough for me to do protocol implementation and perf
testing the NIO loops.
If you think it's useful to work out lower level details while the API
Re : Re : [MINA 3.0] filter chains
De : Emmanuel Lécharny elecha...@apache.org À : dev@mina.apache.org Cc : Envoyé le : Vendredi 26 Août 2011 18h10 Objet : Re: Re : [MINA 3.0] filter chains On 8/26/11 6:02 PM, Edouard De Oliveira wrote: De : Emmanuel Lecharnyelecha...@gmail.com 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 ? DAG is just a restricted form of a FSM. It just forbid a loop, which is exactly what we need in our case (why would we cycle on a filter we already went through ?) The concept is a basic it's just the acronym that may not be known ... -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: [MINA 3.0] filter chains
On 8/26/11 6:16 PM, Alan D. Cabrera wrote:
On Aug 26, 2011, at 9:10 AM, Emmanuel Lecharny wrote:
On 8/26/11 6:03 PM, Alan D. Cabrera wrote:
On Aug 26, 2011, at 8:12 AM, Emmanuel Lecharny wrote:
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
Not at all. :)
Are F, G, H filters inside the FSM or are they external to the FSM?
They are filters in the FSM.
Ok, now I know where you're coming from. For me I have a map of chains
MapState, Chain states = …
State current;
What is Chain in this context ?
I don't think it's enough to build the demux. We probably would need
something like :
MapStatus, Filter filterMap = ...
MapFilter, MapStatus, Filter fsmMap = ...
( I keep Filter, but a Filter for us is a State in a FSM)
otherwise, the controller can't select the next Filter without having a
clue about the context
void send(T message)
{
Chain chain = states.get(current);
current = chain.send(message);
}
What I have in mind is much more something like :
void messageReceived( context )
{
... // do something, updating the context, eventually setting a status
controller.callNextFilter( context, currentFilter );
... // do something after the call
}
and in controller :
void callNextFilter( Context context, Filter currentFilter )
{
Status status = context.getStatus();
MapStatus, Filter map = fsmMap.get( currentFilter );
Filter nextFilter = map.get( status );
nextFilter.messageReceived( context );
}
The controller will decide which filter must be called depending on the
context status.
(Note that the controller should also decide which message to call, for
instance, it can decide that it has to call a messageReceived() because
it's caller was processing a messageReceived())
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA 3.0] filter chains
On Aug 26, 2011, at 9:33 AM, Emmanuel Lecharny wrote:
On 8/26/11 6:16 PM, Alan D. Cabrera wrote:
On Aug 26, 2011, at 9:10 AM, Emmanuel Lecharny wrote:
On 8/26/11 6:03 PM, Alan D. Cabrera wrote:
On Aug 26, 2011, at 8:12 AM, Emmanuel Lecharny wrote:
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
Not at all. :)
Are F, G, H filters inside the FSM or are they external to the FSM?
They are filters in the FSM.
Ok, now I know where you're coming from. For me I have a map of chains
MapState, Chain states = …
State current;
What is Chain in this context ?
Chain is a simple filter or graph of filters that can declare what the next
state of the FSM should be.
I don't think it's enough to build the demux. We probably would need
something like :
MapStatus, Filter filterMap = ...
MapFilter, MapStatus, Filter fsmMap = ...
( I keep Filter, but a Filter for us is a State in a FSM)
otherwise, the controller can't select the next Filter without having a clue
about the context
Ahh, cool, more clarity. I never intended FSMs to replace a demux.
void send(T message)
{
Chain chain = states.get(current);
current = chain.send(message);
}
What I have in mind is much more something like :
void messageReceived( context )
{
... // do something, updating the context, eventually setting a status
controller.callNextFilter( context, currentFilter );
... // do something after the call
}
and in controller :
void callNextFilter( Context context, Filter currentFilter )
{
Status status = context.getStatus();
MapStatus, Filter map = fsmMap.get( currentFilter );
Filter nextFilter = map.get( status );
nextFilter.messageReceived( context );
}
This strikes me as pretty complex, jmho. Also, I don't like the idea of
forcing the filter to call the controller.callNextFilter() to make things work.
Look at my implementation of org.apache.mina.link.DownState as an example.
This framework does not require a call to a controller for the whole thing to
work. This filter merely focuses on its task at hand and implementation does
not leak as much into its message received method.
The controller will decide which filter must be called depending on the
context status.
(Note that the controller should also decide which message to call, for
instance, it can decide that it has to call a messageReceived() because it's
caller was processing a messageReceived())
I feel that, for the most part, we all have been doing a lot of discussions
without any mock implementations of real protocols to help us gauge our API
decisions. Our tendency is to dive into the implementation details and then
shoehorn protocols into the resultant API. This is why Mina 2 is so bloated
and daunting. I'd like to see lots of little sandbox branches where people
show what protocol implementations would end up looking like for the feature
they are proposing. It's a fantastic way to gauge API design differences.
To that end I invite everyone to flesh out, as I am doing in my sandbox branch,
the following protocols:
Link state protocol - implementation of [1]
Group protocol - [2]
Paxos - ideally would use the above protocols
SSL
Checksum
MUX/DEMUX
[1] http://caltechparadise.library.caltech.edu/32/
[2] http://authors.library.caltech.edu/5410/
Regards,
Alan
Re: [MINA 3.0] filter chains
On 8/26/11 7:22 PM, Alan D. Cabrera wrote:
On Aug 26, 2011, at 9:33 AM, Emmanuel Lecharny wrote:
What I have in mind is much more something like :
void messageReceived( context )
{
... // do something, updating the context, eventually setting a status
controller.callNextFilter( context, currentFilter );
... // do something after the call
}
and in controller :
void callNextFilter( Context context, Filter currentFilter )
{
Status status = context.getStatus();
MapStatus, Filter map = fsmMap.get( currentFilter );
Filter nextFilter = map.get( status );
nextFilter.messageReceived( context );
}
This strikes me as pretty complex, jmho. Also, I don't like the idea of
forcing the filter to call the controller.callNextFilter() to make things work.
the alternative would be something like :
void messageReceived( context )
{
... // do something, updating the context, eventually setting a status
fsmMap.get( this ).get( status ).messageReceived( context );
... // do something after the call
}
No controller, but a long list of chained call.
Also the fsmMap must be known by the current filter.
Look at my implementation of org.apache.mina.link.DownState as an example.
This framework does not require a call to a controller for the whole thing to
work. This filter merely focuses on its task at hand and implementation does
not leak as much into its message received method.
Ok, I'll give it a look.
The controller will decide which filter must be called depending on the context
status.
(Note that the controller should also decide which message to call, for
instance, it can decide that it has to call a messageReceived() because it's
caller was processing a messageReceived())
I feel that, for the most part, we all have been doing a lot of discussions
without any mock implementations of real protocols to help us gauge our API
decisions.
I'm lucky enough to have played with MINA for more than 5 years,
facing many differents kind of protocol based on it, plus having
answered many of MINA user's questions regarding how to implement many
different kind of protocol.
Trust me on that, when I'm thinking about the new API, I always have in
mind the different real world protocols we have to deal with. That
includes :
- obviously LDAP protocol, which is a binary, two layer codec, demuxed
protocol
- NTP based on UDP
- Kerberos based on UDP *and* TCP
- HTTP, ie newline terminated decoder, a cumulative decoder
- a few proprietary protocole implemented using MINA, with fixed size
data, or LV type PDUs
Our tendency is to dive into the implementation details and then shoehorn
protocols into the resultant API.
Not exactly my state of mind... I'm more trying to find the best
possible solution, dealing with many constraints :
- ease of use
- coverage of the different use cases
- memory consumption
- ease of debuging
- speed
This is why Mina 2 is so bloated and daunting.
MINA 2 is bloated for different reasons, and I think I have already
discussed some of them.
One of the most problematic reason is that MINA 2 (and 1) was a one man
show. This is why I'm really pleased to have those discussion here, even
if it seems to be a bike-shedding discussion. It is not.
I'd like to see lots of little sandbox branches where people show what
protocol implementations would end up looking like for the feature they are
proposing. It's a fantastic way to gauge API design differences.
I like Julien's approach : designing a working solution, not covering
all our bases right now, and implement a few existing protocols. Then
moving forward.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA 3.0] filter chains
On Aug 26, 2011, at 11:03 AM, Emmanuel Lecharny wrote:
On 8/26/11 7:22 PM, Alan D. Cabrera wrote:
On Aug 26, 2011, at 9:33 AM, Emmanuel Lecharny wrote:
What I have in mind is much more something like :
void messageReceived( context )
{
... // do something, updating the context, eventually setting a status
controller.callNextFilter( context, currentFilter );
... // do something after the call
}
and in controller :
void callNextFilter( Context context, Filter currentFilter )
{
Status status = context.getStatus();
MapStatus, Filter map = fsmMap.get( currentFilter );
Filter nextFilter = map.get( status );
nextFilter.messageReceived( context );
}
This strikes me as pretty complex, jmho. Also, I don't like the idea of
forcing the filter to call the controller.callNextFilter() to make things
work.
the alternative would be something like :
void messageReceived( context )
{
... // do something, updating the context, eventually setting a status
fsmMap.get( this ).get( status ).messageReceived( context );
... // do something after the call
}
No controller, but a long list of chained call.
But we're still forcing the filter to participate in things that really should
be the domain of the controller not the filter.
With that said I think that an FSM where we have, here letters are filters:
[outside filter] - {A - [state change decides to send to] - B - [state
change decides to send to] - C} - [outside filter]
is very confusing. What protocol would require that? Just an honest question;
one does not come to my mind atm.
Also the fsmMap must be known by the current filter.
Look at my implementation of org.apache.mina.link.DownState as an example.
This framework does not require a call to a controller for the whole thing
to work. This filter merely focuses on its task at hand and implementation
does not leak as much into its message received method.
Ok, I'll give it a look.
The controller will decide which filter must be called depending on the
context status.
(Note that the controller should also decide which message to call, for
instance, it can decide that it has to call a messageReceived() because
it's caller was processing a messageReceived())
I feel that, for the most part, we all have been doing a lot of discussions
without any mock implementations of real protocols to help us gauge our API
decisions.
I'm lucky enough to have played with MINA for more than 5 years, facing
many differents kind of protocol based on it, plus having answered many of
MINA user's questions regarding how to implement many different kind of
protocol.
Trust me on that, when I'm thinking about the new API, I always have in mind
the different real world protocols we have to deal with. That includes :
- obviously LDAP protocol, which is a binary, two layer codec, demuxed
protocol
- NTP based on UDP
- Kerberos based on UDP *and* TCP
- HTTP, ie newline terminated decoder, a cumulative decoder
- a few proprietary protocole implemented using MINA, with fixed size data,
or LV type PDUs
I think you missed my point. I am not questioning anyone's expertise in the
industry. I am calling out the current modus operandi of the current API
design process and it's need for real world mockups.
Our tendency is to dive into the implementation details and then shoehorn
protocols into the resultant API.
Not exactly my state of mind... I'm more trying to find the best possible
solution, dealing with many constraints :
- ease of use
- coverage of the different use cases
- memory consumption
- ease of debuging
- speed
Definitely good points. We all want this but they speak nothing to the process
of coming up with an API. My point is to have concrete examples of how the API
bits we are proposing would look. A perfect example is your and my ideas of
how the FSM should work. With no concrete mocked up bits to see how the two
APIs would influence the implementation of a protocol the discussion devolves
into arguments over aesthetic opinions.
This is why Mina 2 is so bloated and daunting.
MINA 2 is bloated for different reasons, and I think I have already discussed
some of them.
One of the most problematic reason is that MINA 2 (and 1) was a one man show.
This is why I'm really pleased to have those discussion here, even if it
seems to be a bike-shedding discussion. It is not.
Agreed on the last bit. Anyone who thinks the current discussions about the
API design are bike shed issues never designed an API.
I'd like to see lots of little sandbox branches where people show what
protocol implementations would end up looking like for the feature they are
proposing. It's a fantastic way to gauge API design differences.
I like Julien's approach : designing a working solution, not covering all our
bases right now, and implement a few existing protocols. Then moving forward.
I'm sorry but
Re: [MINA 3.0] filter chains
On 8/26/11 8:47 PM, Alan D. Cabrera wrote:
On Aug 26, 2011, at 11:03 AM, Emmanuel Lecharny wrote:
On 8/26/11 7:22 PM, Alan D. Cabrera wrote:
On Aug 26, 2011, at 9:33 AM, Emmanuel Lecharny wrote:
What I have in mind is much more something like :
void messageReceived( context )
{
... // do something, updating the context, eventually setting a status
controller.callNextFilter( context, currentFilter );
... // do something after the call
}
and in controller :
void callNextFilter( Context context, Filter currentFilter )
{
Status status = context.getStatus();
MapStatus, Filter map = fsmMap.get( currentFilter );
Filter nextFilter = map.get( status );
nextFilter.messageReceived( context );
}
This strikes me as pretty complex, jmho. Also, I don't like the idea of
forcing the filter to call the controller.callNextFilter() to make things work.
the alternative would be something like :
void messageReceived( context )
{
... // do something, updating the context, eventually setting a status
fsmMap.get( this ).get( status ).messageReceived( context );
... // do something after the call
}
No controller, but a long list of chained call.
But we're still forcing the filter to participate in things that really should
be the domain of the controller not the filter.
If we delegate the transition to the controller, then we can't have post
actions... Obviously, not having post actions makes it easier. (Post
action are really important if we want to do something when we come back
from the application.)
One clear exemple would be a decoder processing a PDU with more than one
message : you can't anymore loop on the PDU if you delegate the next
call to the controller.
With that said I think that an FSM where we have, here letters are filters:
[outside filter] - {A - [state change decides to send to] - B - [state
change decides to send to] - C} - [outside filter]
is very confusing. What protocol would require that? Just an honest question;
one does not come to my mind atm.
all of them :) This is what we currently do in MINA.
Also the fsmMap must be known by the current filter.
Look at my implementation of org.apache.mina.link.DownState as an example.
This framework does not require a call to a controller for the whole thing to
work. This filter merely focuses on its task at hand and implementation does
not leak as much into its message received method.
Ok, I'll give it a look.
The controller will decide which filter must be called depending on the context
status.
(Note that the controller should also decide which message to call, for
instance, it can decide that it has to call a messageReceived() because it's
caller was processing a messageReceived())
I feel that, for the most part, we all have been doing a lot of discussions
without any mock implementations of real protocols to help us gauge our API
decisions.
I'm lucky enough to have played with MINA for more than 5 years, facing many
differents kind of protocol based on it, plus having answered many of MINA user's
questions regarding how to implement many different kind of protocol.
Trust me on that, when I'm thinking about the new API, I always have in mind the
different real world protocols we have to deal with. That includes :
- obviously LDAP protocol, which is a binary, two layer codec, demuxed protocol
- NTP based on UDP
- Kerberos based on UDP *and* TCP
- HTTP, ie newline terminated decoder, a cumulative decoder
- a few proprietary protocole implemented using MINA, with fixed size data, or
LV type PDUs
I think you missed my point. I am not questioning anyone's expertise in the
industry. I am calling out the current modus operandi of the current API
design process and it's need for real world mockups.
Ok, understood. You are reverting the process : we define the protocols,
then we try to implement them with different way to manage filters.
I'd like to see lots of little sandbox branches where people show what
protocol implementations would end up looking like for the feature they are
proposing. It's a fantastic way to gauge API design differences.
I like Julien's approach : designing a working solution, not covering all our
bases right now, and implement a few existing protocols. Then moving forward.
I'm sorry but that seems totally backwards to me. The API design should be the
framework from which the working solution evolves. Starting with the
implementations could automatically close the doors on useful API features.
Unless we ditch those implementations. But I understand your point.
However, even if we define some protocols, we will need some
implementation to test them.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA 3.0] filter chains
On Aug 26, 2011, at 1:27 PM, Emmanuel Lecharny wrote:
On 8/26/11 8:47 PM, Alan D. Cabrera wrote:
On Aug 26, 2011, at 11:03 AM, Emmanuel Lecharny wrote:
On 8/26/11 7:22 PM, Alan D. Cabrera wrote:
On Aug 26, 2011, at 9:33 AM, Emmanuel Lecharny wrote:
What I have in mind is much more something like :
void messageReceived( context )
{
... // do something, updating the context, eventually setting a status
controller.callNextFilter( context, currentFilter );
... // do something after the call
}
and in controller :
void callNextFilter( Context context, Filter currentFilter )
{
Status status = context.getStatus();
MapStatus, Filter map = fsmMap.get( currentFilter );
Filter nextFilter = map.get( status );
nextFilter.messageReceived( context );
}
This strikes me as pretty complex, jmho. Also, I don't like the idea of
forcing the filter to call the controller.callNextFilter() to make things
work.
the alternative would be something like :
void messageReceived( context )
{
... // do something, updating the context, eventually setting a status
fsmMap.get( this ).get( status ).messageReceived( context );
... // do something after the call
}
No controller, but a long list of chained call.
But we're still forcing the filter to participate in things that really
should be the domain of the controller not the filter.
If we delegate the transition to the controller, then we can't have post
actions... Obviously, not having post actions makes it easier. (Post action
are really important if we want to do something when we come back from the
application.)
I think we're getting to some interesting bits. Can you provide more exact
detail?
One clear exemple would be a decoder processing a PDU with more than one
message : you can't anymore loop on the PDU if you delegate the next call to
the controller.
What is the format of this PDU and how is it presented to the FSM, i.e. in what
kind of pieces does it arrive?
With that said I think that an FSM where we have, here letters are filters:
[outside filter] - {A - [state change decides to send to] - B -
[state change decides to send to] - C} - [outside filter]
is very confusing. What protocol would require that? Just an honest
question; one does not come to my mind atm.
all of them :) This is what we currently do in MINA.
I think that I am hearing a reply that explains that all the protocols are
implemented in this way. I'm not hearing an explanation as to why it *must* be
that way.
Regards,
Alan
Re: [MINA 3.0] filter chains
On 8/27/11 2:04 AM, Alan D. Cabrera wrote:
On Aug 26, 2011, at 1:27 PM, Emmanuel Lecharny wrote:
On 8/26/11 8:47 PM, Alan D. Cabrera wrote:
On Aug 26, 2011, at 11:03 AM, Emmanuel Lecharny wrote:
On 8/26/11 7:22 PM, Alan D. Cabrera wrote:
On Aug 26, 2011, at 9:33 AM, Emmanuel Lecharny wrote:
What I have in mind is much more something like :
void messageReceived( context )
{
... // do something, updating the context, eventually setting a status
controller.callNextFilter( context, currentFilter );
... // do something after the call
}
and in controller :
void callNextFilter( Context context, Filter currentFilter )
{
Status status = context.getStatus();
MapStatus, Filtermap = fsmMap.get( currentFilter );
Filter nextFilter = map.get( status );
nextFilter.messageReceived( context );
}
This strikes me as pretty complex, jmho. Also, I don't like the idea of
forcing the filter to call the controller.callNextFilter() to make things work.
the alternative would be something like :
void messageReceived( context )
{
... // do something, updating the context, eventually setting a status
fsmMap.get( this ).get( status ).messageReceived( context );
... // do something after the call
}
No controller, but a long list of chained call.
But we're still forcing the filter to participate in things that really should
be the domain of the controller not the filter.
If we delegate the transition to the controller, then we can't have post
actions... Obviously, not having post actions makes it easier. (Post action are
really important if we want to do something when we come back from the
application.)
I think we're getting to some interesting bits. Can you provide more exact
detail?
One very simple example, taken from the ProfilerFilter :
@Override
public void messageReceived(NextFilter nextFilter, IoSession session,
Object message) throws Exception {
if (profileMessageReceived) {
long start = timeNow();
nextFilter.messageReceived(session, message);
long end = timeNow();
messageReceivedTimerWorker.addNewDuration(end - start);
} else {
nextFilter.messageReceived(session, message);
}
}
If you depend on the controller to call thenext filter, then you have no
easy way to compute the time it takes to process the action, as you
won't be able to execute the post action.
Note that the decoding of multiple messages within one PDU won't be
possible either without being able to process post-actions. (see below)
One clear exemple would be a decoder processing a PDU with more than one
message : you can't anymore loop on the PDU if you delegate the next call to
the controller.
What is the format of this PDU and how is it presented to the FSM, i.e. in what
kind of pieces does it arrive?
You get an array of bytes, containing potentially more than one message.
The fact is that you have no way to get a byte array from the socket as
soon as a complete message has been received : the socket does not know
anything about messages.
You just have to assume that the PDU you've got can be :
- either a portion of a message, and you have to wait for more bytes in
order to produce a message
- a full message, once decoded
- more than one message you have to send to the handler one by one
- some full messages plus a fraction of a message
With that said I think that an FSM where we have, here letters are filters:
[outside filter] - {A - [state change decides to send to] - B -[state
change decides to send to] - C} - [outside filter]
is very confusing. What protocol would require that? Just an honest question;
one does not come to my mind atm.
all of them :) This is what we currently do in MINA.
I think that I am hearing a reply that explains that all the protocols are
implemented in this way. I'm not hearing an explanation as to why it *must* be
that way.
simply because you can't move to the next filter unless you have
transformed what you've got from the previous filter. If we exclude all
the utility filters (like the loggers), a filter can only process a
certain type of message, and produce another type of message. The chain
of filters is dictated by the transformation done at each step. One good
example is LDAP processing : in order to decode a LDAP message, you
first have to decode the TLVs, then you can decode the messages
themselves. A LDAP chain would be something like :
[outside filter] - (bytes) - { TLV decoder filter - (TLVs) - LDAP
decoder filter - (LDAPmessages) } - [outside filter]
(add to this the fact that you may loop on the TLV filter *and* the LDAP
filter, plus the fact that you may have to wait for more bytes)
Now, it makes *no sense* to exchange the filters. It will simply not
work. It's the very same for any protocol we will process with such a
mechanism.
In other words, the order the filters are executed
