> >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.
If you want, you can remove the Cookie class altogether, and I wouldn't
complain (WebDAV doesn't do anything with cookies) ;-)
That's a very isolated change, which is apparently justified. The problem is
with the more important changes which aren't justified in any way except by
the fact that you apparently think the API would be nicer that way.
> >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.
But the API breakage is not justified by any functional requirement, just
that you think it's nicer (and it may indeed be). That's not an acceptable
reason.
> >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.
If I remember well, it still forces some API changes.
> 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.
Hey, I still wrote quite a bit of the code, I think I'm allowed to complain
if I don't agree with some changes. Besides, I'm only complaining about the
refactoring, which you didn't even start to justify.
> 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.
Obviously we don't.
I want whatever is released as 1.0 to be at least 99% binary compatible with
"our" 0.9. That's my goal (indeed, it doesn't look like you share that
goal).
If you want to propose extensive API changes (aka rwaldofrefactoring
branch), you can make a proposal for HTTPClient 2.0. There's no problem with
releasing it one week after HTTP client 1.0 either.
Remy
