On 10/10/10 10:19 AM, Julien Vermillard wrote:
Hi,
Got a bit of time today and I'm back messing with MINA 3.0 code.
I'm actually looking at IoHandler.
I know it's a big API break, but I don't get why we have filters&
IoHandler.For me IoHandler is just a end of chain filter.
I propose to remove it.
Cheers,
After having refreshed my memory, here are some thoughts :
- We have a TailFilter, which is just some glue between the chain and
the Handler. it however does a few useful things :
* sessionOpened(), sessionIdle() just transfer the control to the
handler.
* messageSent() just extract the message from the WriteRequest object.
I question this method though, as the Handler should be able to get it
from the WriteRequest itself, and because the other information
contained into the WriteReqest object might be useful for the IoHandler
* filterWrite(), filterClose() are a bit strange, as they call the
nextFilter, which obviously does not exist.
* sessionCreated() update the ConnectFuture attribute, so the session
can be informed that it has been created
* sessionClosed() calls the IoHandler, then clean the
WriteRequestQueue, the session AttributeMap, the session chain and the
readFutures. It's a bit doubtful that all this logic should be processed
here, when it's more likely to be done before we enter the chain for the
WriteRequestQueue and the readFutures, and after we come back from the
handler for the attributes and the session chain. In fact, the deletion
of the session will already remove all those elements.
* exceptionCaught() method just update the FailFutures, whch could be
done elsewhere too
* messageReceived() updates the statistics and add the message into
the readFutures, I don't have any idea why... (Still hav to figure out this)
Otherwise, the IoFilter interface is way bigger than the IoHandler one,
as it includes all the methods used to manipulate the chain itself
(addition, removal of filters...), somethng we don't need in the IoHandler.
Bottom line, if we remove the IoHandler, that will have some huge impact
on the client side and on the filter side. OTOH, I really think we
should review the IoFilter interface. We already discussed about the
presence of the NextFilter paraeter in all the IoFilter methods, and
this may also have an impact on the refactoring.
I would keep the IoHandler in the picture atm, for convenience, but I'm
not sure we could not remove it soon, if we also redesign the full
filter interface.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
