On Wed, 2010-10-06 at 19:16 +0200, Emmanuel Lécharny wrote: > On 10/6/10 6:54 PM, Oleg Kalnichevski wrote: > > On Wed, 2010-10-06 at 18:13 +0200, Emmanuel Lecharny wrote: > >> On 10/6/10 5:49 PM, Bernd Fondermann wrote: > >>> On Wed, Oct 6, 2010 at 17:37, Oleg Kalnichevski<ol...@apache.org> wrote: > >>>> I apologize for intrusion. > >>> Oleg, no apology needed, I highly appreciate this thread. > >>> Very informative. > >> Indeed. It's probably certain that MINA is lacking documentation, and > >> that it's internal is quite complex. > >> > >> All imputs are very welcome at this stage of design (basically, blue > >> print). > >> > >> In fact, I would be really interested in knowing exactly what kind of > >> service you want to provide on top of NIO/ MINA (if it fits your need), > >> because it ight be useful in the design decision we would take. > >> > > I am developer / maintainer of Apache HttpComponents. We have our own > > NIO framework optimized specifically for data intensive protocols such > > as HTTP, which works quite well for us. However, Apache HC is a small > > project with just a handful of folks involved. If another ASLv2 licensed > > I/O framework met our requirements, we could gradually drop our own NIO > > code thus freeing up bandwidth for HTTP related stuff. Presently, the > > memory management in MINA just kills it for me. Same goes for Netty. > > > > Take it as a food for thought. Nothing more. > I'm going to give HttpComponents a shoot, to see how those two guys can fit. > > One solution would be to define a common base, with all the Filter > intricacy separated from the NIO part. That might fit your need then. >
Yeeeep. This is precisely what I was trying to hint at. 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 Cheers Oleg
