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] Proposed client API in sandbox
Date Fri, 04 Apr 2008 16:36:02 GMT
Agreed.  This is really nice.

On Mar 19, 2008, at 11:39 AM, Mike Heath wrote:

> Sangjin Lee wrote:
>> It looks great!  I went through the APIs, and here are my early  
>> thoughts:
>>
>> [HttpConnectorConfig]
>> - It would be good to support configuring socket parameters  
>> (tcpNoDelay,
>> soLinger, bufsize, ...).
>
> IMO these parameters should be configured through the underlying
> transport implementation.  Because we're passing around buffers, it
> doesn't make a lot of sense to turn off tcpNoDelay and soLinger is
> something that should be managed by the transport.  With MINA 2.0 (and
> perhaps 1.x, I don't remember) the buffer size is dynamic so I don't
> think we would want to expose this in the AsyncWeb API.

Agreed.

>> [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.
>
> In ADBCJ, you have to invoke Future.get() to determine if the request
> succeeded or not.  In same cases it works well, in others it doesn't.

In what cases does it not work well?

> I see two ways of solving the problem:
>
> - Create an abstract implementation of HttpListener that has callback
> methods such as "onSuccess, onCancel, onError, onTimeout".
> - Add methods as you suggested (isSuccessful, isTimedOut, etc.)
>
> Perhaps we should support both approaches.

I think that supporting both approaches would lead to a confusing and  
cluttered API.  I like the idea of Future.get() and, if you want more  
detail, you listen for the instrumentation events.

>> [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.
>
> I think the client should be responsible for validating the cookies in
> the HttpResponse so that neither the CM nor the code that invokes the
> AsyncWeb client have to worry about getting invalid cookies.

Agreed.

> We could have an event that is triggered when we receive an invalid  
> cookie.
>
>> [Some things that exist in the old client but not here]
>> - Authentication support: we could migrate them with minimal  
>> modifications?
>
> We could put the username and password in the URI (i.e.
> http://USER_NAME:SECRET@somehost.foo/) for simple cases.  I would like
> to add support for some type of AuthenticationManager that could be  
> used
> for managing authentication credentials.  The AuthenticationManager
> could also be used to provide a callback for when a request fails  
> due to
> not authenticating (so, in the case of a GUI, for example, a dialog  
> box
> could be displayed prompting the user to enter a username and  
> password).

I like that idea.

>> - Monitoring support based on key events: might be useful for
>> instrumentation and/or monitoring
>
> Yes, this needs to be added.

I looked at this.  About the connect event.  Would it make sense to  
have two events

- Connect
- SSL Negotiation Completed

I think that I would also like a response started event.

If this makes sense to you all, I'll add them to the wiki.

About getHttpClientFactory().  Will all HttpClients be created only by  
HttpClientFactories?  If not maybe we should have an  
HttpClientFactoryGenerated interface that has that method.

Maybe we should have a root interface HttpClientConfigured which  
provides an R/O configuration and HttpClientConfigurable which  
provides an R/W configuration.  We you can see, I favor simple  
disconnected interfaces that implementations would mix and match.

Should HttpClients inherit from HttpClientConfigurable?  Maybe it  
might be a good idea to disconnect and have implementations implement  
both HttpClient and HttpClientConfigurable for those implementations  
where clients are not configurable.

Looking for symmetries between HttpClient and HttpConnector.  If we  
can get an HttpClient's factory, should we not also be able to get  
HttpConnector's factory as well?  HttpClients have  
HttpClientConfigurable, should HttpConnectors not also have one as well?

Again, really nice.


Regards,
Alan



Mime
View raw message