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:22:05 GMT

On Feb 9, 2008, at 7:42 AM, 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.

Not sure why one needs to specify the URL so far in advance.

> 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])

Good stuff.  I'm glad these important features will most likely not  
drive the API.

> 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

Could this not be in the HttpClient?  If we follow the metaphor of a  
browser, it makes sense to store the session there.

> 4) Future objects for any blocking operation

I was thinking that we could have a Future object that implements an  
AHC callback interface.  This would keep the client simple.  Those  
needing synchronous mechanisms could drop in an instance of this  
Future object.  Just trying to prevent something like:


foo = ahc.doAnotherWay();

> 5) The (optional) ability to specify an IoConnector to the client

This could maybe be specified in the factory to use when allocating  


View raw message