hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Becke <be...@u.washington.edu>
Subject Re: DO NOT REPLY [Bug 16729] - Allow redirects between hosts and ports
Date Thu, 24 Jul 2003 03:31:00 GMT
> If my understanding is correct without looking at the source code, the
> purpose of HttpMethodSession is to execute several methods, or one 
> method
> multiple times, in order to follow redirects. So how about 
> HttpMethodChain
> or HttpMethodSequence? Or giving it a more personal name, like
> HttpMethodChainer or HttpRedirector?

Yes, one method multiple times.

I think I like Oleg's HttpMethodDirector the best so far.  There is 
still room for improvement though.  How about HttpMethodCoordinator or 

> As for the 'used' flag, does HttpMethodSession have to execute the same
> HttpMethod object without recycling? If so, you could add a reset() or
> redirect(URI) method that resets the 'used' flag and performs the other
> adjustments required to execute the redirect. Or would it be possible 
> to
> simply recycle the method, just as an application would have to do it?

The same HttpMethod must be re-executed for each retry/redirect.  
Previously this was handled inside HttpMethod so we did not have to 
worry about resetting used externally.   Recycling is not really an 
option as we would have to reconfigure the method each time.  This 
would require knowing or getting all of the values set on the 
HttpMethod.  A reset() method or something of the sort could be added 
to HttpMethod for handling this.  This corresponds to option 2 from my 
previous email.  This is probably the best option assuming that we want 
to keep used at all.

> To keep the getters and setters for options out of a class, I like to
> introduce XxxOptions classes. HttpClientOptions and HttpMethodOptions
> jump into my mind here. All that remains in the original class is one
> getter and setter for the options. When overdesigning, one might define
> an interface with just the getter methods, and a default implementation
> with getters and setters. Just to point out that the class will not
> modify the options passed to it :-)

Sounds like a reasonable approach.  I agree that having a bunch of 
getters and setters is not ideal, though I think this is a separate 
issue.  This should be fixed/redesigned when we get to implementing 
configuration.  For now I prefer keeping this hidden or just unstable 
until we get there.


View raw message