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 NIOlibrary 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'ssome 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 aremore for protocol-level callbacks, such as intercepting headers, etc.. Filters on the NIO level would be for parsing raw-data, which theHttpComponent would then parse and potentially send callbacks out to theinterceptors 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 -- [EMAIL PROTECTED] - http://fotap.org/~osi
smime.p7s
Description: S/MIME cryptographic signature
