Le 4/17/12 12:30 PM, Ashish a écrit :
Folks,
I have started getting into 3.0, now that I have some time. So will
make some noise to get back my rusted mind in shape.
Good ! I can ear your brain knuckles cracking :)
While browsing the code, I saw we have IoHandler and its usage in
AbstractIoService. I vaguely remember that we decided not to have the
IoHandler and last filter in the chain shall be the one that handles
application part (or our IoHandler).
The idea is to not have a dedicated filter at the beginning and at the
end of the chain, yes. The Iohandler should be an interface implemented
by the application. There is no mean to have one empty filter that does
nothing but be the glue between the real filters and your application.
Second query is around the FilterChain processing. Are we keeping
in/out filter chain as separate, or would like to catch up with what
has been done so far :)
That's a bit more complicated. The problem with having one single chain
for ins and outs is that you have to configure the chain to stick with
both in and out processing. That may be complex. OTOH, if we have two
chains, it may be more flexible, but a bit more complex for the users.
Our first approach here is first to get the minimal stack working for
Socket, both client and server, with the correct processing of messages.
We all know how the full thing works, so we can build MINA 3.0 with MINA
2.0 in mind, but avoiding the errors that have been made. That means, we
don't have to throw everything out of the windows, but if we like to do
so, so be it :)
One last thing, I'd like to have an incremental project, where an
addition does not break what we already have added. I don't believe that
a big bang approach is likely to work, I think that baby steps are way
better. But if something that was added does not fit with a new idea you
have, then let's churn the existing stack to fit your new ideas :)
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
