On Monday, July 7, 2003, at 10:46 AM, Ralph Goers wrote:
My 2 cents.
It is ALWAYS possible to maintain binary compatibility. The downside is
that it is ugly and gets unmaintainable over time and it occasionally forces
you to create new classes or methods where you would have liked to have
reuse the old name. Such is life.
An acceptable compromise is to maintain deprecated methods and classes for a
release or two and then remove them.
Ralph
We have spent a fair bit of time looking at ways to fix the problem without breaking API compatibility and I believe at one point someone even created a patch for one of the issues and it was voted down because it introduced far too much instability into HttpClient to make the preservation of the API worthwhile.
This isn't a decision that we've taken lightly and if you're using HttpClient as we've always recommended (check the tutorial in particular) then I'd be very surprised if you noticed any change to the API.
Really, we've spent a lot of time trying to come up with the best solution to these problems and I believe all the developers who've looked at the problem are in agreement that the only realistic way to fix them is to break API compatibility. If you want to spend the time to come up with a maintainable way to solve the problems and maintain API compatibility then by all means feel free.
To summarize the biggest problem with the architecture at the moment:
HttpClient (the class) creates a connection to the host and passes just the connection into the method being executed. The method then handles all the retry/authentication/etc logic and has absolutely no way to create a new connection since that's handled in HttpClient.
Now, if we move the retry logic, we break API compatibility, if we move the creation of connections we break api compatibility.
If we add a new method to HttpMethodBase which accepts a connection manager instead of just a connection and depreciate the old method everyone who would have run into the API change would still have to rewrite their code to use the new method, we still wouldn't have solved all the problems (recreating proxied SSL connections is still not possible), plus the depreciated methods would still have all the bugs that people have been complaining about and the architecture of HttpClient remains unworkable just waiting for the next problem to arise.
At some point we need to move the retry logic out of the methods because it simply doesn't belong there, is very difficult to maintain there and has been causing a lot of problems. When we do that, we have two choices - maintain API compatibility but change the way the methods work (really bad since you won't get any warning that things have changed) or break API compatibility so you get a compile time error. We've chosen the latter.
Note that through all of this, if you're using HttpClient like you should be (ie: actually going through the HttpClient class instead of calling execute on methods directly) you shouldn't see any change.
Hopefully that helps people understand the reasoning behind the proposed changes even if it is a high-level handwaving kind of explanation.
Regards,
Adrian Sutton.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]