On 10/11/10 2:06 PM, Oleg Kalnichevski wrote:
On Sat, 2010-10-09 at 16:58 +0200, Emmanuel Lécharny wrote:
On 10/6/10 9:18 PM, Oleg Kalnichevski wrote:
Here is my private fork of HttpCore NIO code with all HTTP specific
stuff ripped out. It might be easier for you to get a feel of the
framework by looking at the protocol independent code.
http://github.com/ok2c/lightnio
This code is what I would like to get potentially replaced by MINA 3.0
Looking at this code (well, browsing it, I still have to do my homework
;), It seems that the internal logic is really close to what we have in
MINA, and that's quite logical.
I see that the processEvent() method is the place that propagate the
events to the underlying application, and probably what you'd like to
have in MINA to have direct control on the channel if I understand
correctly. There is a slight difference here between lightNIO and MINA
: once we have created a session, it has a Chain of filters attached to
it, and we call the method corresponding to the event we had, which goes
through the chain up to the Handler. This is where you have your
application code. In other words, an application based on lightNIO will
have to implement IoRector, when we require that the application
implement IoHandler in MINA.
Hi Emmanuel
Actually, HttpCore comes with two most common IORector implementations:
listener and connector. What the user code is expected to provide is a
custom implementation of the IOEventDispatch interface. The I/O dispatch
layer is where I/O events get pre-processed and propagated to a protocol
handler. That would be the place to implement a filter pipeline similar
to that employed by MINA.
We have removed the IoHandler class from MINA 3.0 code. That's a first
step toward a more generic approach.
One other difference is that we process the read and write parts into
the main loop (in IoProcessor), something you want to handle directly.
If we remove this processing from the IoProcessor, and move it to be a
Filter (ReadFilter, WriteFilter), then it becomes to be very similar to
what you want : either we add those filters in the chain, and the
application does not have to deal with the read/write operation (buffer
creation and such, queues...), or we let the application to deal with this.
That might work. Still have to think more about the impact on MINA (I
would hate asking MINA users to inject those filters manually. But this
can be the default chain, and we can define another chain without those
filters)
I see no good reason why an I/O framework could not support both modes
equally well or even have a filter pipeline run on top of a Channel
based I/O reactor.
I agree. However, we don't have an event like 'readyToWrite' to inform
the application that the channel is ready to accept some more write
peration. We have to refactor this part, one possible solution would be
to let the user determinate the queue size : if it's zero, then he has a
direct access to the channel, with all the needed control over it.
If you are willing to invest some time into exploring the possibility of
exposing the lower level machinery of MINA through a public interface of
some sort, I would also happily do my bit by helping debug the code and
by contributing a test suite for it.
Work in progress :) As we support many different kind of transports
(Nio, Apr, VmPipe, Serial and potentially plain IO), we would like to
have a common approach for all those transports. That might lead to
major refactoring in MINA code (in fact, we think that MINA 3 will be a
complete rewrite).
Don't expect that we will be ready anytime soon :/
Potentially I could also contribute a pretty much feature complete
SMTP/LMPT transport implementation (both client and server side), which
is currently based on my private fork of HttpCore NIO code (lightnio),
if there is interest.
Of course there is !
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
