hc-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mbe...@apache.org
Subject svn commit: r381245 - /jakarta/httpcomponents/trunk/src/site/apt/goals-scope.apt
Date Mon, 27 Feb 2006 03:24:05 GMT
Author: mbecke
Date: Sun Feb 26 19:24:01 2006
New Revision: 381245

URL: http://svn.apache.org/viewcvs?rev=381245&view=rev
A first stab at reorganizing Goals and Scope


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=381245&r1=381244&r2=381245&view=diff
--- jakarta/httpcomponents/trunk/src/site/apt/goals-scope.apt (original)
+++ jakarta/httpcomponents/trunk/src/site/apt/goals-scope.apt Sun Feb 26 19:24:01 2006
@@ -6,47 +6,37 @@
 Project scope and goals
-    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 was never specifically designed 
-    for: in spiders, in server side services such as HTTP proxies or light-weight HTTP 
-    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
-    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 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 the HTTP request and HTTP response and implies
-    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 it virtually impossible to create a custom 
-    implementation of an HttpMethod interface, essentially rendering it useless. In practice
-    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.
-* 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.
+    The key source of inspiration for Jakarta HttpComponents is the experience gained in
+    developing and supporting Jakarta Commons HttpClient. The following set of goals are
+    derived from our experience with HttpClient and serve as the philosophical foundation

+    to HttpComponents.
+* Componentized design
+    * People use HTTP in varied and unexpected ways such as spiders, HTTP proxies, web servers,

+    web clients, and many more.  To offer the kind of flexibility need from 
+    an HTTP library, HttpComponents provides a generic toolkit of components that can be
+    for any task, large or small.
+    * HTTP functionality is broken into a set of key components that focus on making the
+    most commonly used code the simplest.  Specialized code has been separated to
+    enhance API clarity while still providing the features needed for complex applications.
+* Cleanly structured API
+    * HttpComponents provides separate interfaces for HTTP request and response processing.
+    Combining these two seemingly associated items forces an impractical limitation on 
+    HTTP processing.  As discovered in our original work with HttpClient, not all requests
+    just on response. In many cases the code producing a request is quite distinct from 
+    the code processing the response.
+    * HttpComponents is assembled from groups of cooperating classes rather than through
+    This makes it quite simple for someone to completely customize a single aspect of the
+    process without effecting other unrelated tasks.  It also makes it simple to make changes
+    that cut across different kinds of requests (GETs, POSTs, etc).  Again this design remedies
+    one of the major deficiencies discovered in the HttpClient model.
+* Minimal external dependencies
+    * HttpComponents strives to remove the need for any unnecessary external dependencies,
+    logging.  In our experience external libraries only complicate integration for users.

View raw message