On Aug 19, 2011, at 5:16 AM, Emmanuel Lecharny wrote: > On 8/19/11 1:55 PM, Alan D. Cabrera wrote: >> On Aug 19, 2011, at 4:16 AM, Julien Vermillard 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/org/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 ;) >> I ran into a different scenario that dictated the same result. For me, >> often times when a message is sent or received no message is passed on so my >> protocol had to always return a null. This always seemed awkward to me. >> Also, then that dictated that I had to check for nulls in the framework, >> also not so good. >> >> Take a look at my class org.apache.mina.link.UpState to see what I mean. > > We should not compare filters and pipes. Think about the whole mechanism as > if it was a state machine, because it is. The only relation between two > states are those dicatetd by the transition we allow. We don't transite from > one state to another one randomly, so are the data passed from one state to > another : they are well known by both the initial and the final states.
I'm not sure that I'm following. What is this data that you speak of? > We should then make no general presumption about the received and sent data. > If one state does not require anything, fine : the caller will know it. OTOH, > if we can have multiple data to send to the next state, then we just have to > loop and call as many times the next step as necessary. I'm not sure that I'm following. Who is the caller and why does he need to know all this? Regards, Alan
