mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <l...@toolazydogs.com>
Subject Re: [AsyncWeb] Client redesign
Date Sat, 09 Feb 2008 23:32:47 GMT

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



View raw message