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. > 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. 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. 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. Cheers Oleg
