Why do we pass the current position? We also seem to pass it twice in the method and the controller.
Regards, Alan On Aug 19, 2011, at 1:10 PM, Julien Vermillard wrote: > Ok I committed the modification, for passing a chain controller to the > filter for delegating the call to next filter. > > First I did it only for read & write chaining because the other events > (created,open,closed,idle) are fine like they are. They don't need to > block an event or send it multiple time to the following filter. > > Here the modified IoFilter, some controller interface are passed to > read & write events : > http://svn.apache.org/repos/asf/mina/branches/3.0/core/src/main/java/org/apache/mina/api/IoFilter.java > > > Here sample implementation of LoggingFilter : > http://svn.apache.org/repos/asf/mina/branches/3.0/core/src/main/java/org/apache/mina/filter/logging/LoggingFilter.java > > Here the FilterChain implementation, still simple : > http://svn.apache.org/repos/asf/mina/branches/3.0/core/src/main/java/org/apache/mina/filterchain/DefaultIoFilterChain.java > > Now I need to figure how to remove the current position argument of > the filter call. > > Julien > > > On Fri, Aug 19, 2011 at 2:46 PM, Julien Vermillard > <[email protected]> wrote: >> I half implemented the controller idea, it's looking like working, >> I'll finish that during the weekend or next week and commit it for >> review. >> Julien >> >> On Fri, Aug 19, 2011 at 2:39 PM, Steve Ulrich <[email protected]> >> wrote: >>> Hi! >>> >>> Besides the points you mentioned, there are some other flaws: >>> 1) How do you handle post-message-forwarding logic? >>> 2) How do you handle filters that transparently push messages to the >>> underlying filters (e.g. keep alive)? >>> >>> So the filters should decide about what to do, the chain about the where. >>> >>> regards >>> >>> Steve >>> >>> There could be specific (empty, single-result, multi-result) >>> implementations that can be extended as needed. >>> >>>> Julien Vermillard [mailto:[email protected]] wrote: >>>> >>>> Hi, >>>> I implemented some really simple chain for MINA 3 based on a list of >>>> chain processed by a filter chain. >>>> >>>> The implementation is very simple, sounded like a good idea : >>>> http://svn.apache.org/repos/asf/mina/branches/3.0/core/src/main/java/or >>>> g/apache/mina/filterchain/DefaultIoFilterChain.java >>>> >>>> But when i started implementing an HTTP codec I started to see the >>>> real design issues. >>>> The problem is when you need to produce more than one object during a >>>> filter processing, like when you find more than one PDU in a >>>> ByteBuffer. >>>> >>>> We could change IoFilter method : >>>> Object messageReceived(IoSession session, Object message); >>>> To : >>>> List<Object> messageReceived(IoSession session, Object message); >>>> >>>> But starting to use collection here sound like an overkill and not >>>> really a nice idea if we want to keep the memory usage low enough. >>>> >>>> So I'm scraping the current implementation, I'm going to try something >>>> else suggested by Emmanuel : >>>> When a filter want to call the next filter, he ask it to the filter >>>> controller (aka the FilterChain). Let's see if it's going somewhere >>>> this time ;) >>>> >>>> Julien >>
