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 <steve.ulr...@proemion.com> 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:jvermill...@gmail.com] 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
