[off-list] Re: using httpclient without a HttpClient object (wasRedirects?)

[Jeffrey Dever]

Hey Eric,

I know I sounded rash. I just wanted to entice people that never post to share their views, not incite revolt! I was also in a bit of a bad mood when I sent that off. It showed. I try to build an image of being level headed, but there I cracked.

   * We should not remove functions from the APIs unless they are
     already deprecated.  To do otherwise will cause people to abandon
     HttpClient (again!) as unstable.  Rather, we should maintaining
     deprecated functionality, with a good idea as to when it will be
     removed.

Total agreement. In some cases this was unrealistic to deprecate the old functionality and add the new. In other cases some things were removed without deprecation if they had never been in a release build. HttpClient is somewhat special because it was 14months between releases. I have not been around that long, last June, but from what I can tell, it was basicly left on the floor in worse state than it was in its 1.0 release. Fragmented, missing peices, methods and classes that made no sense. A lot of really great people have risen up here to work on it which is fantastic.

   * Instead of removing the execute() method, we might deprecate it
     and add a sibling function called "executeWithoutRetry()" - OK,
     that is a bad name, but you hopefully get the idea.

I was thinking of deprecating and then later making it package access. If sun had added a keyword for package level access, rather than making it the unnamed default, I bet we would have more package level classes and methods. I struggle with the number of classes and methods that are needlessly public.

   * I believe strongly in exposing interfaces, rather than instances,
     something HttpClient could do more of.  If you take that approach,
     though, you can make the interfaces public, but the
     implementations package access, thus discouraging certain uses
     without actually preventing them.  In other words, if a client can
     figure out how to correctly implement the "HttpConnectionIntf"
     interface, you are welcome to do so (at your own risk), and call
     HttpMethod.execute() directly.

Interfaces are good, and are under-utilized in Java in general and HttpClient in particular. But they can be problematic if the interface is not fully described up front. If users are implementing it (and in some cases are expected to do so) then simply adding a neglected method breaks their code with no warning, with no way to provide a default interface. In many cases, I prefer abstract base classes.

   * I couldn't decide whether the "redirect" functionality is
     something that should be "pushed down" or "pulled up".  Is is
     something that HttpMethodBase delegates to another class to do for
     it, or is HttpMethodBase considered "dumb", and not responsible
     for retries, but instead relies on its caller to do for it?  This
     would speak to the need to deprecate the execute method at all.

It seems to me that redirection is client functionality not method functionality.

I agree that it certainly isn't too late to add this change, but am strongly in favor of designing in such a way as to maintain compatibility.

Yes, yes I agree. I never feel that I'm doing any design however. The object model, interaction, sequences and structure are already defined, frequently in ways I don't like or disagree with. So all I do is add some functionality, fix bugs, refactor methods. Most of my sofware experience is in new development, and I'm still learning the art of maintaince. I'm mostly in administration mode now anyway, so I''ll concentrate on that more and shoot my mouth off less.
Jandalf.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]