On Wed, Feb 13, 2008 at 3:04 PM, Mike Heath <[EMAIL PROTECTED]> 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?
That sounds like a good approach. Still some necessary normalization (like
something I see in DefaultHttpRequest.normalize()) would need to happen in
both cases, no?
>
> > 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.
I suspect this would be an HttpListener in your class proposal. We could
provide a completion queue as an HttpListener. Callers can then simply add
the queue to their future to handle it. Yeah, I'm not too enthused about
adding the queue to the APIs, although that's what we ended up doing. :)
One nice thing about the completion queue is that it can be used with
multiple HttpClients as well.
>
>
> 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 think in general some amount of knowledge about the request is unavoidable
on the response. If the response object has no knowledge of what the
request was, there will be certain things that are not possible to do.
There may be many examples, but one example I can think of is inspecting
the Set-Cookie header to accept or reject cookies. Things like domain and
path validation are needed but that requires the request. AHC's
HttpResponseMessage also does not know about the request, and it's been a
pain point.
>
>
