Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta-httpclient 
Wiki" for change notification.

The following page has been changed by OlegKalnichevski:
http://wiki.apache.org/jakarta-httpclient/ProjectGoalsPage

------------------------------------------------------------------------------
- = Project scope and goals =
+ Moved to SVN
  
- 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. 
- 
- === 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 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 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 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 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 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 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
- 

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to