It looks great! I went through the APIs, and here are my early thoughts: [HttpClient] - Would a common usage be one HttpClient instance per host? It's not very clear to me whether one instance can be used against multiple hosts or it can be used only for a given host. Specifically, for the following method
List<HttpRequestFuture> get(String... uris) must all uris be against the same host, or can they go to various hosts? The javadoc "pipelining" suggests they must go all against the same host... [HttpConnectorConfig] - It would be good to support configuring socket parameters (tcpNoDelay, soLinger, bufsize, ...). - One thing that we may want to see is supporting optional connection retries. [HttpFuture] - Should we support Future.cancel()? Whether we can truly cancel these asynchronous operations here is bit tricky... [HttpListener] - onComplete() would be invoked not only if there is a response ready but also if there was an exception or a timeout on the response, correct? How would one determine one case against another? Perhaps it might be a good idea to provide a few convenience methods that let you determine exactly which case (not unlike mina's IoFuture implementations). Some suggestions include boolean isSuccessful(): terrible name for lack of a better alternative boolean hasException() boolean isTimedOut() Throwable getException() We could simply say that one should call Future.get() and react according to the outcome (whether it returns a result as opposed to throwing an executor exception) but the above seems more direct and more convenient. [CookieManager] - Would it also encapsulate the logic of accepting and validating cookies coming from the server (i.e. handling the "Set-Cookie" header)? For example, validation on the domain attribute needs to be done against the request host name. Also, default values for the domain and the path attributes need to be determined per spec before storing the cookies. [Some things that exist in the old client but not here] - Authentication support: we could migrate them with minimal modifications? - Monitoring support based on key events: might be useful for instrumentation and/or monitoring - Being able to insert an executor filter for isolating the codec and post-operations - Proxy configuration: support for exclusion lists Thanks, Sangjin On Tue, Mar 18, 2008 at 1:56 PM, Mike Heath <[EMAIL PROTECTED]> wrote: > The proposed new AsyncWeb client API is available here for your viewing > pleasure: > http://svn.apache.org/repos/asf/mina/sandbox/mheath/asyncweb/client/ > > I've taken into account a lot of the feedback I've received so far. > Some of the big changes include: > > - I've separated the HttpClientFactory and the HttpConnector. The > HttpConnector provides HttpConnection objects which can be thought of as > a step above a MINA IoSession. The HttpClientFactory produces > HttpClient instances that provide a friendlier interface to issuing > asynchronous HTTP requests. The configuration options have been > separated as well > - The HttpFuture object has get/setPayload methods that allow the user > to arbitrarily associate an object with the future (this is an idea > borrow from the JSR 203 IoFuture). > - I added an HttpRequestFuture interface that extends HttpFuture and > returns the HttpRequest object used to initiate the request > - I added support for sending HttpRequest objects directly > - I added PartialResponseListener for dealing with large responses. > This has the same name as an interface proposed by Julien for the server > API so we may need to change the name and/or discover overlap with the > server side of the framework > - I added some configuration options for HTTP proxy settings > > Some of the things that we need to work on still > - We still need to add something analogous to the IoServiceListener in > MINA or the Event mechanism in AHC > - We need some way for configuring different encoding mechanisms (i.e. > gzip encoding) > - Caching - good caching and support for ETag would be a big plus > > I'm thinking that a HttpClientFactory would use a HttpConnector under > the hood. This would allow us to implement HttpClientFactory and > HttpClient once and be able to plug in any transport that implements > HttpConnector. We can also implement connection pooling by creating a > HttpConnector implementation that proxies another HttpConnector that > does the actual network communication. > > It's still a work in progress so please tell me what you don't like and > what could be improved. > > -Mike >
