On Feb 9, 2008, at 3:22 PM, Alan D. Cabrera wrote:
On Feb 9, 2008, at 7:42 AM, David M. Lloyd wrote:
4) Future objects for any blocking operation
I was thinking that we could have a Future object that implements an
AHC callback interface. This would keep the client simple. Those
I think that this bit can be, and is, handled with URLs. I don't see
the advantage of adding complexity to the metaphor and, hence, the API.
This isn't a metaphor, it's an API. Using a metaphor to help conceptualize
what you're trying to accomplish can be helpful, but there's no point in
Alan D. Cabrera wrote:
On Feb 9, 2008, at 3:22 PM, Alan D. Cabrera wrote:
On Feb 9, 2008, at 7:42 AM, David M. Lloyd wrote:
4) Future objects for any blocking operation
I was thinking that we could have a Future object that implements an
AHC callback interface. This would keep the
David M. Lloyd wrote:
The limitation on what would be allowed on a connection URI is the reason
that I suggested earlier that the API could accept discrete scheme,
hostname,
and port parts - since the rest of the URI is not useful anyway. But since
either method satisfies the requirements
Tuure Laurinolli wrote:
Of course, the casual user probably doesn't care about connection
pooling, and possibly not even about pipelining and keep-alive, he just
wants a component that takes an HttpRequest, does some magic and gets an
HttpResponse back to the callback he gave to the component.
David M. Lloyd wrote:
Yes, this is my thinking as well - the casual user wants a simplified API,
while the advanced user wants a more detailed interface.
Certainly no reason not to offer both capabilities ;-)
Jeff
- DML
Alan D. Cabrera wrote:
I see and take your point. It is six of one and half a dozen of
another. What I'm confused about is why we need to initially specify
anything outside of the actual request. What problem are we trying to
solve? Maybe I'm misunderstanding what you are espousing so let
On Feb 10, 2008, at 10:35 AM, David M. Lloyd wrote:
Alan D. Cabrera wrote:
On Feb 9, 2008, at 3:22 PM, Alan D. Cabrera wrote:
On Feb 9, 2008, at 7:42 AM, David M. Lloyd wrote:
4) Future objects for any blocking operation
I was thinking that we could have a Future object that implements
On Feb 10, 2008, at 10:05 AM, David M. Lloyd wrote:
I think that this bit can be, and is, handled with URLs. I don't
see the advantage of adding complexity to the metaphor and, hence,
the API.
This isn't a metaphor, it's an API. Using a metaphor to help
conceptualize
what you're
Going back on some of the points here...
On Jan 29, 2008 2:25 PM, Mike Heath [EMAIL PROTECTED] wrote:
Connecting - Connecting is done as a blocking operation. In Jeff
Geneder's AHC branch in the Geronimo sandbox, thread pools are being
used for asynchronous connecting. This is unfortunate
First off, I agree with what's under consensus so far in this thread.
Great to see more people get involved! :)
2008-02-09 (토), 17:01 -0800, Alan D. Cabrera 쓰시길:
On Feb 9, 2008, at 3:56 PM, Mike Heath wrote:
Alan D. Cabrera wrote:
snip
That's a good thought. The reason that the URL
On Feb 11, 2008 1:28 AM, Mike Heath [EMAIL PROTECTED] wrote:
Jeff Genender wrote:
David M. Lloyd wrote:
Yes, this is my thinking as well - the casual user wants a simplified
API,
while the advanced user wants a more detailed interface.
Certainly no reason not to offer both
Jeff Genender wrote:
David M. Lloyd wrote:
Yes, this is my thinking as well - the casual user wants a simplified API,
while the advanced user wants a more detailed interface.
Certainly no reason not to offer both capabilities ;-)
I totally agree. I think we should offer a very simple
Most of the statements I made were referring to the AsyncWeb client code
and not the latest AHC code that came over from Geronimo. There is a
huge difference here and I think that's what led to a lot of the
confusion over the statements I made.
-Mike
Sangjin Lee wrote:
Going back on some of
David M. Lloyd wrote:
Alan D. Cabrera wrote:
snip
So, I was thinking that you would send requests like so:
ahc.send(url, listener);
This is a departure from the rest of MINA though, in which the idiom
is more like this:
ahc.send(request).setListener(listener); // does not block
To
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
David M. Lloyd wrote:
3) Session things like cookie management should be maintained at a
higher level - maybe even a separate HttpSession object that can be
provided to each request, on a read-only or read-write basis
I hope higher level here means that people who actually use HTTP in
On Feb 9, 2008, at 7:42 AM, David M. Lloyd wrote:
Alan D. Cabrera wrote:
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
Alan D. Cabrera wrote:
snip
That's a good thought. The reason that the URL was originally put in the
HttpClient constructor (as well as the request) was to allow the
management
of connections to be separated from the URL request. Realistically, a
URL
could be dropped in favor of discrete
On Feb 9, 2008, at 12:13 PM, Mike Heath wrote:
David M. Lloyd wrote:
Alan D. Cabrera wrote:
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
Mike Heath wrote:
I like the idea of specifying a base URI for the HttpClient. So you use
a base URI of something like http://somedomain.foo; and subsequent
requests could then do something like get(/bar) which would do a GET
on http://somedomain.foo/bar;.
This would require further
On Feb 9, 2008, at 3:56 PM, Mike Heath wrote:
Alan D. Cabrera wrote:
snip
That's a good thought. The reason that the URL was originally put
in the
HttpClient constructor (as well as the request) was to allow the
management
of connections to be separated from the URL request.
On Feb 9, 2008, at 4:29 PM, David M. Lloyd wrote:
Mike Heath wrote:
I like the idea of specifying a base URI for the HttpClient. So
you use
a base URI of something like http://somedomain.foo; and subsequent
requests could then do something like get(/bar) which would do a
GET
on
On Jan 29, 2008, at 2:25 PM, Mike Heath wrote:
Now that Alex has an AsyncWeb subproject going, I've finally taken the
time to look over the client code. I have some feedback about the
client and what I would like to see change. We also discussed the
client on IRC and I will summarize some of
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
-
Mike Heath wrote:
[...]
This topic came up on the IRC channel and David Lloyd (dmlloyd), Tuure
Laurinolli (tazle), and I (mike_heath) were discussing better
alternatives to the current design. The following is a summary of our
conversation.
And while Mike was typing up this excellent summary,
Hi guys,
I'm fine with anything y'all select for the name. I'm much more interested
in figuring out how to get some of these resource issues settled and the two
forks of this merged together so we have more people working together on
this. Please see my thread on how to bring the Geronimo folks
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
28 matches
Mail list logo
