On 8/26/11 4:28 PM, Alan D. Cabrera wrote:
On Aug 26, 2011, at 7:12 AM, Julien Vermillard wrote:
On Fri, Aug 26, 2011 at 4:07 PM, Emmanuel Lecharny<[email protected]> wrote:
On 8/26/11 3:44 PM, Alan D. Cabrera wrote:
On Aug 26, 2011, at 6:40 AM, Julien Vermillard wrote:
On Fri, Aug 26, 2011 at 3:24 PM, Alan D. Cabrera<[email protected]>
wrote:
On Aug 26, 2011, at 4:14 AM, Julien Vermillard wrote:
I modified the API to remove IoFilterChain. Now you are supposed to
give a list of filter to the service before starting it :
// create the fitler chain for this service
List<IoFilter> filters = new ArrayList<IoFilter>();
filters.add(new LoggingFilter("byte log filter"));
filters.add(new MyCodecFilter());
filters.add(new LoggingFilter("pojo log filter"));
filters.add(newMyProtocolLogicFilter());
acceptor.setFilters(filters);
acceptor.bind(...);
How do we make chains where two filters feed into one or one filter
feeds two filters? If you look in my sandbox we can accommodate this via:
static import a.m.util.Util. linkParentWithChild; // to be written
IoFilter foo = new FooFilter();
LinkStateFilter link = new LinkStateFilter();
IoFilter checksum = new ChecksumFilter();
IoFilter log = new LogFilter();
link.addLinkStateListener(foo);
linkParentWithChild(foo, checksum);
linkParentWithChild(link, checksum);
linkParentWithChild(checksum, log);
acceptor.setFilters(foo);
About the code in the sandbox :
http://svn.apache.org/repos/asf/mina/sandbox/adc/ahc/mina3/src/main/java/org/apache/mina/core/IoFilter.java
I see no IoFilter.addLinkStateListener(..) method, am I looking at the
right place ?
Oops, it was meant to just be a sketch. :)
About the "filters feed into one or one filter feeds two filters", do
you have a concrete use case in mind for that ?
The above example does, Foo and the link state filter. I'm sure that
we've discussed this before. Another example is a mux/demux situation. How
would all of this fit into the grand scheme of things?
Yeah, it really should be a graph of filters, not a list of filters.
Well if it's just for demuxing I proposed few mails ago this solution
: http://s.apache.org/A9W
I think we need to make graphing a 1st class citizen and not buried inside
another filter class.
I do agree. The proposed solution on http://s.apache.org/A9W is what we
currently have, and it's tedious to manage.
It would be way better to be able to let the controler call the next
filter based on an evaluation method based on the current state.
Now, the question is : how do the controller knows which filter to call
next ? It must have the current state, and it must be able to make the
connection.
For instance, let's say that from filter F we can switch to either
filter G or filter H, depending on the state we transit to in F.
F --(state1)--> G
or
F --(state2)--> H
That means the controller has a map { (F, state1, G), (F, state2, H)}
somewhere. State should be passed to the controller too :
...
controller.nextFilter( newState );
...
Pretty theorical at this point... I'm sorry not to have a lot of time to
code this, I do realize that for you guys implementing ideas it's a PITA...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
