On Mon, 2006-07-31 at 19:21 +0100, Irving, Dave wrote: > I've been having a dig around the http components site, but I cant > really see a clear picture of the goals of http nio. > Maybe this is because, as you say, all options are still on the table. > So its not currently clear to me that there is necessarily a large > amount of overlap. The key principle of asyncweb is not that it uses NIO > - rather that it is asynchronous in its dispatch through the "container" > (service, endpoint, whatever you want to call it). > It is this freedom which makes it useful (scalable) in gateways and > other (potentially) high latency usage scenarios. >
I think the overlap between HttpComponents and Asyncweb will be quite significant. Both projects will end up developing HTTP protocol logic that sits on top of a lower level I/O model. The only difference between projects is likely to be the fact that Asyncweb is based on MINA, whereas HttpComponents strive to be self-contained (no external dependencies for core components) and adaptable to any I/O model. HttpComponents will provide primitives for the classic (blocking) I/O model as well as for the asynchronous, event driven I/O model. > I believe asyncweb also presents a fairly intuitive asynchronous API, as > well as making it very easy to drop in IoC configured services and > manage routing to those services. All of this is already well defined > and in use today by some other folks (Xfire, Xwire, Glassfish, Restlet > and possibly Mule in the near future). > There also seems to be a healthy number of people keen to get involved > with developing project when it (hopefully) comes to MINA in the near > future ( http://www.nabble.com/-pre-proposal--AsyncWeb-tf1931092.html ). > > For these reasons, I think its worthwhile giving asyncweb a chance to > grow within Mina and see where we end up. Fair enough. I understand. Cheers, Oleg
