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

[Jeffrey Dever <js...@sympatico.ca>]

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.