hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kalnichevski, Oleg" <oleg.kalnichev...@bearingpoint.com>
Subject RE: [VOTE] Add commons-codec as an HttpClient dependency
Date Wed, 16 Jul 2003 14:50:33 GMT

It may be too a strong opinion, but I am convinced 2.0 API is not worth a single hour of further
development beyond bug fixes. I will also strongly object any cross-site redirect fix at the
expense of overall quality. I think we have spent enough time already coming up with all sorts
of creative ways of bending 2.0 API and it simply did not work. There's no way I take part
in anything similar to HttpMethodBase#fakeResponse method.

If it is just about release numbers, let us call it HttpClient 3.0, or HttpClient 3.1, or
HttpClient NT, or HttpClient.NET, or HttpClient Whatever, but I finally want to be able to
do things right


-----Original Message-----
From: Michael Becke [mailto:becke@u.washington.edu]
Sent: Wednesday, July 16, 2003 16:26
To: Commons HttpClient Project
Subject: Re: [VOTE] Add commons-codec as an HttpClient dependency

Kalnichevski, Oleg wrote:
> Right, but the problem is those folks who use CVS snapshots while
> insisting on complete (maximum) API compatibility with 2.0 branch.
> They have not been quite receptive to 'but it was part of our plan
> for 2.1' kind of arguments up to now.
> Of course, I can put up the same 'Evil Comrade' act as always, but I
> have a feeling that some of them did not quite appreciate my sarcasm.

No need to resort to the 'Evil Comrade'.

I have been looking into standard versioning techniques 
<http://jakarta.apache.org/site/versioning.html> in order to get some 
perspective on this.

On the positive side, it seems that for a minor release (what we are 
doing) it is okay to add an external dependency.  So, if we ever plan to 
add codec we might as well do it now.

On the negative side, we are supposed to be making only 
external-interface-compatible changes.  In general this has been our 
goal, but we have removed some deprecated methods which is a no-no.  We 
may also have some difficulty with this when it comes to redirects.

This makes we wonder if our plans for 2.1 are compatible with a minor 
release.  Granted we can bend the rules a little with the consensus of 
HttpClient users but I want to keep from going too far.

I suggest we consider resurrecting the removed deprecated code (ever 
though it was nasty and I am glad it is gone).  I also think we should 
start looking closely at how we will accomplish our plan to move 
redirect/retry logic to HttpClient.


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

View raw message