Thanks! > enough people willing to contribute to it. I see no point in developing > it all by myself, as I am not a great believer in benefits of NIO model > for client side HTTP in the first place.
Actually, in my very first analysis, I think I may be in an architecture that requires NIO at both server & client sides. To sum up, I need to build kind of transcoding proxy, supporting thousands of client connections and connecting to a few web sites on behalf of those clients. That would allow managing client requests as fast as possible to the backend web servers without blocking sending threads. For sure, I want to prototype before and found your interesting code. > The async client currently lack even the most basic features and nowhere > near production quality. Currently it is nothing more than HttpCore NIO > plus connection pooling. Ok. It is a good starting point for me, no more :-) On Mon, 2010-02-08 at 11:49 +0100, DELHOSTE Fabrice wrote: > Hi, > > In the scope of an important project, I'm strongly interested in the > high-level asynchronous http client (pooling, ...) available only in the SVN repo rather than reinventing the wheel (round if possible ;-) > I've read the exchange discussed a few months ago and the code drop. > > What's the status today on this toolkit? Is it planned to become part of > HttpCore NIO? It may eventually evolve into a subproject within HC provided there are enough people willing to contribute to it. I see no point in developing it all by myself, as I am not a great believer in benefits of NIO model for client side HTTP in the first place. > Do you think it is far from production quality? The async client currently lack even the most basic features and nowhere near production quality. Currently it is nothing more than HttpCore NIO plus connection pooling. > If not, what would you recommend as a reliable HTTP client layer with > pooling/server facilities, ... ? > I took a very brief look at the latest Jetty HttpClient and had an impression it was always buffering the entire response body in memory, which in my opinion makes it unfit for anything other than highly special use cases where content entity are known to be of limited length. I may well be wrong, though, as I only had a cursory look at the source code. Oleg > Thanks, > Fabrice > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
