Re: [httpclient] [proposal] Remove the "httpclient/methods/Url*Method " classes

[Davanum Srinivas <di...@yahoo.com>]

+1 to removing them.

Thanks,
dims

--- Jeff Dever <jd...@nortelnetworks.com> wrote:
> 
> [PROPOSAL]
> 
> Delete the 6 Url*Method classes and reimplement the functionality in a way
> that makes sense.
> 
> 
> [REASONING]
> 
> The httpclient/methods package has the following classes:
> http://cvs.apache.org/viewcvs/jakarta-commons/httpclient/src/java/org/apache
> /commons/httpclient/methods/
> DeleteMethod
> GetMethod
> HeadMethod
> OptionsMethod
> PostMethod
> PutMethod
> UrlDeleteMethod
> UrlGetMethod
> UrlHeadMethod
> UrlOptionsMethod
> UrlPostMethod
> UrlPutMethod
> 
> Each *Method has a Url*Method wrapper.  I was not around when these were
> added, but I think that these are a really bad idea.  I would guess that
> they were to make up for the fact the the constructors for the *Method
> classes would only take a path as a String, but sombody wanted to pass in a
> full URL String, so wrappers for every *Method were created.
> 
> I would say that this was a bad design decision, for several reasons:
> 
> 1) The behaviour that these classes represent could have been implemented
> without change to the API.  The constructor of HttpMethodBase could have
> been modified to allow either a path or a full Url to be passed in, and to
> parse it appropriately.  Or another constructor that takes a URL object as a
> parameter.
> 
> 2) The number of method classes has been multiplited by 2.  This sets up a
> very bad pattern for future changes in an API and I would consider it
> serious "API Bloat".
> 
> 3) The Url*Methods are all broken: they take a String URL as a parameter,
> but ignore the protocol, host and port.  All that is parsed out is the path
> and querystring.  This is completely unexpected behaviour.
> 
> 
> They were added in February this year and have never been included in a
> tagged build.  Therefore there is no need to depricate them and they can be
> removed according to the Commons Versioning guidelines.  I should stress
> that now is the time to remove them, before the next 2.0 milestone, as they
> will be more difficult to change afterwards (and they really don't work).
> http://jakarta.apache.org/commons/versioning.html
> 
> 


=====
Davanum Srinivas - http://xml.apache.org/~dims/

__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>