hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Berlin" <sber...@gmail.com>
Subject Re: [HttpNIO] MINA and AsyncWeb
Date Mon, 17 Jul 2006 17:59:06 GMT
Hey Pete,

Like Roland mentioned, I've been planning for a while to adapt a version of
HttpAsync to be backed by NIO components.  I had taken a look at MINA, but
was likely going to use LimeWire's NIO package, since my main desire is to
incorporate the end-result into LimeWire.  HttpClient is the second-to-last
piece of I/O left in LimeWire that's still using blocking I/O.  Our NIO
library is much like MINA, supporting chained readers & writers.

HttpAsync / HttpComponents both seem very flexible, so it should be possible
to create a project that can delegate to any NIO library (so long as there's
some kind of common ground between them).

>From what I understand, the interceptors on the HttpComponents level are
more for protocol-level callbacks, such as intercepting headers, etc..
Filters on the NIO level would be for parsing raw-data, which the
HttpComponent would then parse and potentially send callbacks out to the
interceptors after parsing things such as headers.


On 7/17/06, Roland Weber <http-async@dubioso.net> wrote:
> Hi Pete, hi Odi,
> the first shot on HttpAsync will be based on blocking IO,
> and I don't see that becoming obsolete because of NIO.
> While I've heard all kinds of talks about NIO, I myself
> have never had to do with it so far. It's been Oleg and,
> to some degree, Sam Berlin who have the expertise. From
> what I picked up, NIO will require a new application API.
> That's a new set of entities that are read from or written
> to channels instead of streams. HttpAsync in it's first
> iteration really is about asynchronous (not non-blocking)
> communication with the traditional stream based API.
> We can start talking, and discussing how the architectures
> match. But I don't expect this to go far until Oleg is back.
> Peter, from what you wrote it sounds as if MINA filters
> are more or less similar to HttpComponents interceptors.
> Overlap is there, now we need to see how this can be
> leveraged.
> cheers,
> Roland
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message