hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Jakarta-httpclient Wiki] Update of "ProjectGoalsPage" by OlegKalnichevski
Date Sun, 06 Nov 2005 21:27:57 GMT
Dear Wiki user,

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

The following page has been changed by OlegKalnichevski:

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

=== 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

View raw message