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] Ideas for client
Date Fri, 29 Feb 2008 08:03:03 GMT

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.


View raw message