Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 25966 invoked from network); 8 Aug 2002 18:40:14 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 8 Aug 2002 18:40:14 -0000 Received: (qmail 574 invoked by uid 97); 8 Aug 2002 18:40:39 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 521 invoked by uid 97); 8 Aug 2002 18:40:39 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 503 invoked by uid 98); 8 Aug 2002 18:40:38 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Message-ID: <98EE0985BBB7D411BE5A0002A507E7F901063513@obelix.calpurnia.com> From: Xiaowei Jiang To: "'Jakarta Commons Developers List'" Subject: RE: [httpclient] [proposal] Remove the "httpclient/methods/Url*Me thod " classes Date: Thu, 8 Aug 2002 11:38:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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: For additional commands, e-mail: