Re: [HttpNIO] MINA and AsyncWeb

[Sam Berlin <sb...@gmail.com>]

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.

Sam

On 7/17/06, Roland Weber <ht...@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
>
>

Re: [HttpNIO] MINA and AsyncWeb

[Sam Berlin <sb...@gmail.com>]

> Ah, so I need to lobby you to put MINA underneath your LimeWire NIO
> interfaces? ;)


Heh, that'd be quite a lobbying effort. :)  The NIO layer's stabilized
nicely, is tested on millions of consumer-level machines and works well.
I'm planning to separate it into a jar so that other projects can use it
too.


> I took a peek at the interfaces.. and seem similar to Mina.. main
> difference being that MINA pushes the data through the chain where
> your interfaces indicate to members that they can pull data?


Kinda.  Reading pulls, writing pushes.


>
> btw, i'm in nyc as well, would be happy to sit down over coffee/tea/
> beer to hack/discuss some of this :)


Cool.  I'll email you off-list.

Sam

Re: [HttpNIO] MINA and AsyncWeb

[peter royal <pr...@apache.org>]

On Jul 17, 2006, at 1:59 PM, Sam Berlin wrote:
> 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.

Ah, so I need to lobby you to put MINA underneath your LimeWire NIO  
interfaces? ;)

I took a peek at the interfaces.. and seem similar to Mina.. main  
difference being that MINA pushes the data through the chain where  
your interfaces indicate to members that they can pull data?

> 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).

This would be great as well.. Since there are certainly  
commonalities.. Everyone has to parse headers out of a ByteBuffer :)

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

In MINA, you could map interceptors into a MINA IoFilter. The  
"events" that flow through MINA's filter chain (akin to Servlet  
Filters) are by default ByteBuffers, but for protocols, it is common  
to have a filter that converts the ByteBuffer into a java object  
representing the protocol item. Thus, an interceptor could be wrapped  
in a MINA IoFilter and intercept a "HTTP Header" object being sent  
through the chain.

btw, i'm in nyc as well, would be happy to sit down over coffee/tea/ 
beer to hack/discuss some of this :)

-pete

-- 
proyal@apache.org - http://fotap.org/~osi