hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kalnichevski, Oleg" <oleg.kalnichev...@bearingpoint.com>
Subject RE: doubt on HttpClient design regarding HttpMethod
Date Mon, 22 Sep 2003 09:47:32 GMT

>From what I know of HttpClient's historical background the project started as a spin-off
of a bigger one. Many design decisions that were perfectly OK for a bare-minimum library with
a limited scope turned out quite constraining once HttpClient started to evolve into a comprehensive
general-purpose HTTP toolkit. The first generation of HttpClient developers is long gone already
and we can only guess as to why certain things have been designed the way they are today.

We are perfectly aware of many shortcomings of the existing design (including this one) and
are planning to embark on a complete API overhaul right after 2.1 release. HttpMethod interface
split into HttpRequest/HttpResponse pair is the very first item on our to-do list



-----Original Message-----
From: Elankath, Tarun (Cognizant) [mailto:ETarun@blr.cognizant.com]
Sent: Monday, September 22, 2003 11:33 AM
To: commons-httpclient-dev@jakarta.apache.org
Subject: doubt on HttpClient design regarding HttpMethod

Hi all,

I am new to HttpClient and was reading through its "Getting started" section. What struck
me immediately is that HttpMethods are full-fledged objects of their own in HttpClient. I
think this is a great idea.

However, I don't understand why HttpClient couldn't have something like a HttpResponse object
that is returned when execute() is called. It just seems a bit kludgy to call getResponse()
on the HttpMethod object itself.

Was there a design reason on why this was done ?

PLUS: I am enjoying this library. Thank you for it!


To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org

View raw message