hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Weber <ROLWE...@de.ibm.com>
Subject Re: [POLL] Minimal JRE requirement for HttpClient 4.0
Date Wed, 26 Jan 2005 20:04:51 GMT
Hi Chris,

"Chris Brown" <chris92250@hotmail.com> wrote on 26.01.2005 19:55:18:

> Turning the problem on its head, it seems like HttpClient 4 is intended 
> be a really complete package...  Are there any features that aren't 
> for say HttpClient 4 that might be implemented in HttpClient 5 (that 
> already thought of) ?

The High Level Design at
includes several components "Provided there is a healthy community around 
Of course we hope, but we'll have to see how much (contributing) community
there is. We are striving for an architecture that lasts for quite some 
but not everything we think of will actually be available in 4.0.

> The worry about choosing a JDK is that some new features might not be 
> available on platforms that are at present, if I'm correct.  How about 
> making HttpClient 1.3+ compatible, then say making HttpClient 5 to run 
> Java 5, no new features, just a new implementation that takes advantage 
> Java 5's new and useful stuff..?

Let me take a pragmatic view here: Oleg is the guy that will do most of 
programming for 4.0. He's been waiting for this chance to overhaul the API
for years, and he's eager to finally use java.nio features. I think we
should let him have his way :-)

Adrian Sutton has made valid points about 1.3 compatibility, and being one
of Ye Old Ones (aka committers ;-), his voice will not go unheard. So I
currently think the best way is to unleash Oleg on a 1.4 version and make
it as easy as possible to backport to 1.3. But the development effort for
the 1.3 version will have to come from people that actually want to or
have to use HttpClient on a 1.3 platform.
That is only my personal opinion, of course. This poll is not over yet,
and the voting hasn't even begun.
(anyone offended by the fluffy wording, please accept my apologies)

Development of a version that does not offer new features but has 
requirements is not likely to happen. At least it would have to be way 
(which could be considered a feature) to make the effort worthwile.


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