hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sung-Gu" <jeri...@apache.org>
Subject A design
Date Tue, 17 Dec 2002 08:55:51 GMT
I'd like to add my comment for the new future architecture.

Have anyone been considering to apapt the provider and listener for
What if it's adapted, every body can see explicitly the data processing and
communication functions.
It's dealt with the method beans including header beans in the httpclient
message container.
Then URL/URI would be a type of bean normally.

I'm just curious that there are somebody considering this kinda design...


----- Original Message -----
From: "Kalnichevski, Oleg" <oleg.kalnichevski@bearingpoint.com>
Subject: Let's face it: HttpClient API is more complex that it could have

It's not the best time to discuss API changes at this point of time when the
focus should be put on polishing the existing code. However, I can't help
thinking that the HttpClient API could have been a bit more
straight-forward. Quite a few of the recent postings on this mailing list
were made by people having problems figuring out HttpClient's modus
operandi. Lack of documentation is partially to blame, but complex API does
not make things easier either. I was sort of thinking of an easy way to
explain how to get started with the


Bottom line:
- ideally HttpMethod interface should be split into HttpRequest/HttpResponse
- HttpClient.execute() should always work with full URLs. I feel that
client.getHostConfiguration().setHost(host, port); client.execute(path)
sequence is unnecessarily complex.
- The purpose of HttpMethod.recycle() may not be obvious to some
- We should think of a browser as a paradigm for HttpClient's "modus
operandi": start the damn thing, hit that url, get response, move to the
next one

View raw message