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.


Regards,
Alan



Mime
View raw message