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
