On Feb 13, 2008, at 3:04 PM, Mike Heath wrote:
Sangjin Lee wrote:
What I've seen with AHC is that the configuration is often the most
challenging aspect. One metaphor I used is that HttpClient is
more like a
browser. Things like keep-alive, user-agent, accept-encoding,
etc. normally
belong to the browser and not at the individual request level.
I'm sure
there are many delicate decisions to make that don't get solved
easily by
this metaphor, but I think it's certainly useful.
This is the metaphor I would like to follow is well which is why in my
API proposal I didn't provide a mechanism for sending a raw
HttpRequest
object through the HttpClient.
After reviewing all the feedback and thinking about the problem more,
I'm thinking that if the user submits a MutableHttpRequest, then the
HttpClient will modify that request as appropriate. If the
HttpRequest
does not implement MutableHttpRequest, then the request will be sent
unmodified. I think this should solve the problem adequately. WDT?
I think we should keep things crazy simple until we have a problem we
need to solve. Maybe you are and I don't see it. Can you explain
why we need to use HttpRequest in the HttpClient?
I've mentioned this before, but one thing I like with AHC is handling
multiple requests with a completion queue (not unlike
CompletionService).
This addresses a use case which is a variation of one of Mike's
use cases.
Suppose you want to send requests to N URLs concurrently. You
want to limit
the overall duration to a certain time, and you want to place a
standard
error result for the URL for which the response did not get in
time. This
is a pretty typical situation with a "scatter-and-gather" scenario
(e.g.
portal with multiple server-side content aggregation, etc.).
With a completion queue, one can do things like the following:
CompletionQueue q;
client.send(request1, q);
client.send(request2, q);
...
client.send(requestN, q);
for (int i = 0; i < N; i++) {
Future f = q.take();
Response r = f.get();
}
This can be done by the user in terms of a listener/callback, but
it would
certainly be nice to provide support for this... My 2 cents.
I too really like the idea of using a Queue for handling futures. It
opens up a lot of interesting possibilities.
The problem I see is for each method in HttpClient, do we provide an
overloaded version that accepts a Queue? This would make the API very
cluttered IMO.
We use an HttpListener to add the completed future to the queue. See
the following example.
BlockingQueue q;
queueListener = new QueueListener(q);
client.send(request1).addListener(queueListener);
client.send(request2).addListener(queueListener);
client.send(request3).addListener(queueListener);
client.send(request4).addListener(queueListener);
for (int i = 0; i < N; i++) {
Future f = q.take();
HttpResponse r = f.get();
}
The problem with this approach is that with the AsyncWeb client
API, as
I've proposed it, there would be no way to know which request the
future
object represents because we don't know the order in which each
HttpListener will be invoked.
I'm not sure how we keep track of requests in Sangjin's proposal
either. If we can't, then your solution is an elegant equivalent.
Regards,
Alan
