>Every change in the "bugs fixes" and "functional enhancement" categories of
>your list can be introduced without
>any API breakage (or I missed something).
Well, actually, no. For (just one) example, Cookie.parse previously didn't
even know the port, path or security of the request in question, so it is
not possible to make that method sensitive to paths, ports or security
without changing that API.
>Sorry, but while the bug fixes are more than welcome, the refactoring
>itself looks rather gratuitous to me. In terms of API design, there's no
>limit to fanciness.
If you can honestly look at the HttpClient/HttpMethodBase pair in the main
branch versus the refactored version and only characterize the changes as
"gratuitous" "fanciness" then I guess we won't be making much progress.
If you'd care discuss substantive complaints, let's do that.
>I appreciate the good will you mention here :
>... but I don't trust you too much on API compatibility issues, given what
>you already did with the logging.
This is both petty and inaccurate. You'll note that the logging/debugging
stuff was changed more than once specifically to support Slide.
Do you think I'm doing this just to spite the Slide project? I have a need
for a bug-free, well-factored, well-documented and well-tested HTTP client
implemenation. I have contributed many hours to ensuring that httpclient is
just that. And I have gotten nothing but flack every step of the way. Silly
of me to think we may have a common goal here.
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
