On Feb 9, 2008, at 12:13 PM, Mike Heath wrote:
David M. Lloyd wrote:
Alan D. Cabrera wrote:
I like the metaphor of a browser. The HttpClientFactory is nice as
the holder of the shared resources. The HttpClient can be thought
of
as a browser. It holds cookies, etc. With that said, the URL
belongs
in the request not the HttpClient constructor.
That's a good thought. The reason that the URL was originally put
in the
HttpClient constructor (as well as the request) was to allow the
management
of connections to be separated from the URL request.
Realistically, a URL
could be dropped in favor of discrete scheme/hostname/port
parameters on
an connection object. Though it's not always desirable to do this,
so
specifying and maintaining a physical connection should be an
optional kind
of thing to do.
I'm not picky as far as API goes, but I'd like to see the following
(many
of these items have been stated by others, but here's a roundup):
1) The ability to control connections independently of requests
2) Pipelining & keepalive (which should be a direct consequence of
[1])
3) "Session" things like cookie management should be maintained at a
higher level - maybe even a separate "HttpSession" object that can be
provided to each request, on a read-only or read-write basis
3a) "HttpSession" should be a interface of some type, so the user can
intercept cookie reads and writes and act on them directly
4) Future objects for any blocking operation
5) The (optional) ability to specify an IoConnector to the client
Hope I'm making sense.
There are a lot of different use cases that need to be addressed in
the
AsyncWeb client API. I've got a small laundry list of use cases
rattling around in my head that I would like support in AsyncWeb.
Do we
have a wiki available for AsyncWeb where we can start posting some of
our ideas
We can drop our ideas down in this
http://cwiki.apache.org/confluence/display/AHC/Index
Regards,
Alan
