DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16729>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16729 Allow redirects between hosts and ports ------- Additional Comments From [EMAIL PROTECTED] 2003-07-24 03:37 ------- Oops... I originally sent this to the mailing list but meant to post is here. > 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 ClassThatDoesStuffWithHttpMethods:) > 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. Mike --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
