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? -Mike
