hc-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mbe...@apache.org
Subject svn commit: r381113 - /jakarta/httpcomponents/trunk/src/site/apt/goals-scope.apt
Date Sun, 26 Feb 2006 16:08:09 GMT
Author: mbecke
Date: Sun Feb 26 08:08:07 2006
New Revision: 381113

URL: http://svn.apache.org/viewcvs?rev=381113&view=rev
Log:
Wording changes to goals and scope

Modified:
    jakarta/httpcomponents/trunk/src/site/apt/goals-scope.apt

Modified: jakarta/httpcomponents/trunk/src/site/apt/goals-scope.apt
URL: http://svn.apache.org/viewcvs/jakarta/httpcomponents/trunk/src/site/apt/goals-scope.apt?rev=381113&r1=381112&r2=381113&view=diff
==============================================================================
--- jakarta/httpcomponents/trunk/src/site/apt/goals-scope.apt (original)
+++ jakarta/httpcomponents/trunk/src/site/apt/goals-scope.apt Sun Feb 26 08:08:07 2006
@@ -6,47 +6,47 @@
 
 Project scope and goals
 
-    Jakarta HttpComponents project represents an effort to produce a new generation of HTTP

-    components based on our experience with developing Jakarta Commons HttpClient and an

-    attempt to address the shortcomings of the existing API found in HttpClient 2.0 and 
-    HttpClient 3.0 series of products.
+    The key source of inspiration for Jakarta HttpComponents is the experince gained in
+    developing and supporting Jakarta Commons HttpClient. The shortcomings and inefficiencies

+    listed below emerged during our work with HttpClient. This project is an attempt to 
+    address these issues.
 
 * Monolithic design of Commons HttpClient
 
     * The use patterns of Commons HttpClient have evolved much since its first release. We

-    have found HttpClient used in applications it has not never been specifically designed

+    have found HttpClient used in applications it was never specifically designed 
     for: in spiders, in server side services such as HTTP proxies or light-weight HTTP 
-    connectors. Essentially we see HttpClient users trying to use it as a toolkit of generic

+    connectors. Essentially we saw HttpClient users trying to use it as a toolkit of generic

     HTTP components. In some areas the original monolithic design of Commons HttpClient 
     proved quite lacking.
 
     * HttpClient has a rich set of features. Some of them, however, are used infrequently
in 
-    a limited number of specific cases and represent unnecessary code bloat for a sizable

+    a limited number of specific cases, and represent unnecessary code bloat for a sizable

     percentage of HttpClient users. Moreover, some of those infrequently used features in

     Commons HttpClient were introduced at the expense of the API clarity. There are some

-    core HTTP components that are required by any HTTP service either on the client or on
the 
+    core HTTP components that are required by all HTTP services whether they be on the client
or on the 
     server side. More application specific aspects of HTTP, however, cannot be adequately

     represented by one monolithic library. 
 
 * Inherent API deficiencies of Commons HttpClient
 
     * HttpMethod interface, one of the most fundamental interfaces in Commons HttpClient,

-    is inherently flawed. It tightly couples HTTP request and HTTP response and implies one

+    is inherently flawed. It tightly couples the HTTP request and HTTP response and implies
one 
     to one relationship between the two, which is not always the case.
 
     * Abuse of inheritance. HttpMethodBase class contains the greatest chunk of processing

     logic in HttpClient. It inseparably couples the logic of generating HTTP requests and

-    processing HTTP responses. This makes virtually impossible to create a custom 
-    implementation of HttpMethod interface rendering it completely useless. In practice all

+    processing HTTP responses. This makes it virtually impossible to create a custom 
+    implementation of an HttpMethod interface, essentially rendering it useless. In practice
all 
     HTTP methods must be derived from HttpMethodBase class.
 
     * The fact that all HTTP methods in practical terms must be derived from one common 
     base (HttpMethodBase) has a number of side effects. For instance, if one needs to
     introduce a common behavior across all standard HTTP methods, one would have to 
-    subclass all the existing subclasses of the HttpMethodBase: GetMethod, PostMethod, etc

+    subclass all the existing subclasses of the HttpMethodBase: GetMethod, PostMethod, etc.
 
 * External dependencies
 
     * One of the most frequently cited complaints is its dependency on Commons Logging and

     Commons Codec. We would like to give the users an option to use core HTTP components

-    without any external libraries and a minimal footprint 
+    without any external libraries and a minimal footprint.



Mime
View raw message