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] Client redesign
Date Sat, 09 Feb 2008 08:20:46 GMT

On Feb 8, 2008, at 11:27 PM, Alan D. Cabrera wrote:

>
> On Jan 29, 2008, at 5:46 PM, Tuure Laurinolli wrote:
>
>> David M. Lloyd wrote:
>>
>>> So basically there's been a number of suggestions as to what to  
>>> name these things.  Here are the two options:
>>> Name from pastebin     Option 1              Option 2
>>> ---------------------  --------------------  ----------------------
>>> AsyncHttpClient        HttpClientFactory     HttpClient
>>> HttpRequestor          HttpClient            HttpConnector
>>> HttpFuture             HttpFuture            HttpFuture
>>
>> Going with Option 1, I took a look at what the current MINA AHC  
>> would look like with this API - the result is at http://www.laurinolli.fi/~tazle/http-client-trivial-implementation.patch

>>  It isn't exactly like current AHC (it's not possible to close  
>> connections at the moment), but pretty close. The AHC tests run,  
>> for example.
>>
>> This implementation gets rid of the resource leaks caused by  
>> constantly creating and not disposing NioSocketConnectors, but does  
>> not even try to address pipelining or large requests.
>>
>>> Of course nothing is decided until everyone has had a chance to  
>>> weigh in.
>>
>> Indeed - I don't particularly like the code I wrote, but I think it  
>> needed to be written in order to see what hoops there were to jump  
>> through. I think the HttpHandler and HttpFuture interfaces are bad,  
>> especially the way IoHandler events are converted into HttpFuture/ 
>> HttpHandler events. HttpClient on the other hand seems like an  
>> interface we should have. It seems ideal for hiding the complexity  
>> of possible pipelining or request pooling.
>>
>
> I like how this thread is going.  But I can't help but think that  
> we're driving the API from the implementors' standpoint and not the  
> users.  IMO, we need to start with a metaphor.  The one that I  
> envision is not too far from what's being discussed but points out  
> some, what I feel to be, deficiencies in what you propose Tuure.
>
> I like the metaphor of a browser.  The HttpClientFactory is nice as  
> the holder of the shared resources.  The HttpClient can be thought  
> of as a browser.  It holds cookies, etc.  With that said, the URL  
> belongs in the request not the HttpClient constructor.

Bah.  Catching up on other threads...


Regards,
Alan


Mime
View raw message