[Jakarta-httpclient Wiki] Update of "ProjectGoalsPage" by OlegKalnichevski

[Apache Wiki <wi...@apache.org>]

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

New page:
= 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. 

=== 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 sited 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: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org