RE: [httpclient] [proposal] Remove the "httpclient/methods/Url*Me thod " classes

[Xiaowei Jiang <xi...@stratify.com>]

I completely agree with Jeff on this issue. These classes can be merged into
the other set of *Method classes. It won't create any backward compatibility
issue since it's never released. It will also make it clear to a first time
user on what they should use.

xiaowei

-----Original Message-----
From: Jeff Dever [mailto:jdever1@nortelnetworks.com]
Sent: Thursday, August 08, 2002 11:02 AM
To: Jakarta Commons Developers List
Subject: [httpclient] [proposal] Remove the
"httpclient/methods/Url*Method " classes



[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


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