On Fri, Feb 29, 2008 at 12:03 AM, Alan D. Cabrera <[EMAIL PROTECTED]>
wrote:
>
> 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
>
>
Keeping track of the requests is a concern that exists in both proposals.
Thanks,
Sangjin
