Mailing-List: contact commons-httpclient-dev-help@jakarta.apache.org;
 run by ezmlm
Message-ID: <3E5C37D9.2070304@sympatico.ca>
Date: Tue, 25 Feb 2003 22:43:21 -0500
From: Jeffrey Dever <jsdever@sympatico.ca>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.0.2) Gecko/20021120 Netscape/7.01
MIME-Version: 1.0
To: Commons HttpClient Project
 <commons-httpclient-dev@jakarta.apache.org>
Subject: Re: Significant HttpClient & HttpMethodBase overhaul. Need early
 	feedback
References: 
 <0AC2D75550100F4DBDB025D4D0561188770481@BIGCOW.intraephox.ephox.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


To implement this feature (full redirects), there are really only three 
general choices that make sense:

1) augment HttpMethodBase.execute()
Pros: current functionality is maintained
Cons: makes complex code more complex,

2) have two stage redirection done partially in HttpMethodBase and part 
in HttpClien
Pros: migration path for redirect logic to eventually be all in HttpClient,
Cons: would be a hack prone to error

3) move and augment redirect logic into HttpClient.execute(
Pros: most logical seperation of concerns, does simplify HttpMethodBase, 
Oleg has an initial patch
Cons: breaks user code

 From the work that Oleg has done, and the comments here, it seems clear 
that redirect logic should be in HttpClient.  Clearly Oleg is on the 
right track with his work, and I agree this is the best approach.  The 
problem is that con is a pretty big drawback.  I'd say it is to late in 
the development cycle to make such a change, no matter how rewarding.

I did not realize how big of a deal true redirects was going to be to 
implement.  Oleg's patch gives us a good base and evaluation platform, 
but perhaps we should consider putting this feature on the back burner 
and do it in 2.1.

Jandalf.


Adrian Sutton wrote:

>>The only good reason I can see for going with a two-loop solution is the 
>>fact that we're fairly close to a final release right now and might want 
>>to keep the code stable.  On the other hand, if we're going to make a 
>>semantic API change like this, it's probably better to do it now, before 
>>2.0 final.
>>    
>>
>
>Personally, I feel it's too late in the release process to be moving all the
>redirect code around, however that does depend on how inelegant the other
>options are.
>
>If we don't move it until after the 2.0 release, we should add a note on any
>method that is likely to be affected by the change that the change will
>happen and so you shouldn't depend on this code being here.  (Much like
>Sun's warning about serializing Swing objects).
>
>I'd also suggest that we make HttpClient more flexible so that Laura can use
>it directly since that would then discourage people from using the methods
>directly and changes like this will be much less of a concern in the future.
>
>Course, I don't have time to actually do any of this, so feel free to just
>ignore me. :)
>
>Adrian Sutton, Software Engineer
>Ephox Corporation
>www.ephox.com
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>
>
>  
>