Mailing-List: contact httpcomponents-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <httpcomponents-dev@jakarta.apache.org>
Received-SPF: neutral (herse.apache.org: local policy)
Subject: Re: current state of httpclient 4.0
From: Oleg Kalnichevski <olegk@apache.org>
To: HttpComponents Project <httpcomponents-dev@jakarta.apache.org>
In-Reply-To: <3fb8d2f00706100344g58d9f093i8acf60978e2eebde@mail.gmail.com>
References: <3fb8d2f00706100344g58d9f093i8acf60978e2eebde@mail.gmail.com>
Content-Type: text/plain
Date: Sun, 10 Jun 2007 13:16:10 +0200
Message-Id: <1181474170.28486.28.camel@okhost>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Sun, 2007-06-10 at 12:44 +0200, Daniel Mueller wrote:
> Hi all,
> 
> In what state is the new version of the httpclient? I checked it out from
> SVN and it seems to be using the new httpcore underneath. I think you have
> refactored the original httpclient into two projects, so the two are fully
> functional. Is that correct?

This is correct. As we leaned from our experience of building and
maintaining HttpClient 3.x there were many cases where monolithic
HttpClient proved not flexible enough, primarily when used in proxies of
some kind or by web crawlers. So, we wanted to make HttpClient more
modular to enable users to assemble their own custom HTTP services in a
piecemeal fashion. Currently we maintain two independently versioned
modules: HttpCore and HttpClient, but we are open to accepting more
components into the fold _provided_ there are enough contributors to
maintain them.  

>  And since my main interest lies in the nio part
> of the httpcore, what needs to be done to have this part working with the
> httpclient (if there's anything which is not working, not sure about that)?
> Some pointers would be great, so I can speed up my understanding of the
> code.
> 

This used to be and still is a major point of contention. I believe NIO
makes very little sense for 'pure' HTTP servers and clients. To date NIO
has always tended to be significantly slower than classic I/O as long as
the number of I/O worker threads was below several thousands. I still do
not see a valid use case where a pure HTTP client may need more than
just a handful of I/O threads (a few hundred at most). That basically
eliminates all advantages of NIO for HttpClient. 

Having said all that, I am very, very, very open to helping people build
client side components based on HttpCore NIO to be used in some HTTP
proxy or gateway services. 

Hope this clarifies things somewhat

Cheers

Oleg


> Cheers,
> Daniel


---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org