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.
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.
At least, this is my vision...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
