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:[EMAIL PROTECTED]/) 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
