I guess one of the things that I'm truing to understand is why do we need that index? Why should that be exposed to the filter implementer?
Regards, Alan On Aug 19, 2011, at 11:56 PM, Julien Vermillard wrote: > Here another idea (not really sure it's a good one) > > http://nopaste.info/0c43874851.html > > It would be regrouping session created/open/close in one IoFilter > method, with a SessionEvent are a parameter. > > I doesn't change much the inner logic, but perhaps it can make > impelemention of IoFilter less verbose. > WDYT ? > Julien > > On Sat, Aug 20, 2011 at 8:49 AM, Julien Vermillard > <jvermill...@gmail.com> wrote: >> Hi, >> Because a filterchain can be shared across different sessions and >> threads, so you need to pass the local chain index because you can >> store it locally in the filter chain. Perhaps there is something >> smarter to do, because it's the dark point of this API. >> >> Julien >> >> On Sat, Aug 20, 2011 at 12:41 AM, Alan D. Cabrera <l...@toolazydogs.com> >> wrote: >>> 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 >>>> <jvermill...@gmail.com> 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 <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 >>>>> >>> >>> >>
