It's been over a month since this discussion started. It seems like
we have some core consensus on a lot of things. So, I was curious
about how we should proceed. I'm not sure how this community usually
proceeds so I'll just toss out an idea.
I thought that Mike had a made good start
On Mar 3, 2008, at 12:22 PM, Sangjin Lee wrote:
I haven't had a chance to add my use case: the scatter-and-gather
situation where one uses a completion queue to handle the result.
Hopefully
I'll do that some time this week...
I also would like to discuss how to get back to the request
On Fri, Feb 29, 2008 at 12:03 AM, Alan D. Cabrera [EMAIL PROTECTED]
wrote:
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
I haven't had a chance to add my use case: the scatter-and-gather
situation where one uses a completion queue to handle the result. Hopefully
I'll do that some time this week...
I also would like to discuss how to get back to the request while processing
the response. It is often desirable and
On Feb 29, 2008, at 2:55 PM, Mike Heath wrote:
Alan D. Cabrera wrote:
So, HCF can be optional. If you create HCs directly any cookies that
are created are scoped w/ that client. The HCF would take an
implementation of a CookieManager (CM) interface. I guess HC could
as
well.
That's
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
Alan D. Cabrera wrote:
On Feb 11, 2008, at 5:27 PM, Mike Heath wrote:
I posted some use cases here:
http://cwiki.apache.org/confluence/display/AWEB/ClientUseCases They
still need some refinement to properly convey what I want but they're a
decent start.
I've added some the use cases
On Feb 11, 2008, at 5:27 PM, Mike Heath wrote:
I posted some use cases here:
http://cwiki.apache.org/confluence/display/AWEB/ClientUseCases They
still need some refinement to properly convey what I want but
they're a
decent start.
I've added some the use cases that I need to support.
On Wed, Feb 13, 2008 at 3:04 PM, Mike Heath [EMAIL PROTECTED] 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,
Sangjin Lee wrote:
snip
That sounds like a good approach. Still some necessary normalization (like
something I see in DefaultHttpRequest.normalize()) would need to happen in
both cases, no?
normalize() is defined in the MutableHttpRequest interface so in the
case of a mutable request we
Mike Heath wrote:
snip
I think in general some amount of knowledge about the request is unavoidable
on the response. If the response object has no knowledge of what the
request was, there will be certain things that are not possible to do.
There may be many examples, but one example I can
2008-02-12 (화), 23:57 -0700, Mike Heath 쓰시길:
이희승 (Trustin Lee) wrote:
2008-02-12 (화), 11:16 -0700, Mike Heath 쓰시길:
Eero Nevalainen wrote:
Btw, what was the status of DNS resolution in MINA? I remember that at
some point DNS resolving used the blocking java API calls. I could
imagine
On Feb 13, 2008 10:07 AM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote:
2008-02-12 (화), 23:57 -0700, Mike Heath 쓰시길:
이희승 (Trustin Lee) wrote:
2008-02-12 (화), 11:16 -0700, Mike Heath 쓰시길:
Eero Nevalainen wrote:
Btw, what was the status of DNS resolution in MINA? I remember that
at
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
Eero Nevalainen wrote:
Btw, what was the status of DNS resolution in MINA? I remember that at
some point DNS resolving used the blocking java API calls. I could
imagine that an asynchronous HTTP-client would have to perform a lot of
DNS queries(or not, depending on use). Could this become a
Mike Heath wrote:
Rick McGuire wrote:
The one feature I like about the AHC client that appears to be missing
here is the higher-level abstraction of an HTTP request. The one
drawback of doing everything with URLs is the requirement that the user
of the client needs to be responsible for
This is very cool to hear Matteo! I will definitely have to take a look
at your code. It would be nice to integrate some of this into MINA.
-Mike
Matteo Merli wrote:
Hi,
I've started an asyncronous DNS client based on MINA for my HTTP
caching proxy (also based on MINA:
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
2008-02-12 (화), 11:16 -0700, Mike Heath 쓰시길:
Eero Nevalainen wrote:
Btw, what was the status of DNS resolution in MINA? I remember that at
some point DNS resolving used the blocking java API calls. I could
imagine that an asynchronous HTTP-client would have to perform a lot of
DNS
Hi,
I've started an asyncronous DNS client based on MINA for my HTTP
caching proxy (also based on MINA:
http://alijo.googlecode.com )
The client is based on the code from the DNS server in Apache Directory.
The implementations is not complete yes as :
* Only returns first IP address in the
Rick McGuire wrote:
Mike Heath wrote:
Rick McGuire wrote:
The one feature I like about the AHC client that appears to be missing
here is the higher-level abstraction of an HTTP request. The one
drawback of doing everything with URLs is the requirement that the user
of the client needs to
이희승 (Trustin Lee) wrote:
2008-02-12 (화), 11:16 -0700, Mike Heath 쓰시길:
Eero Nevalainen wrote:
Btw, what was the status of DNS resolution in MINA? I remember that at
some point DNS resolving used the blocking java API calls. I could
imagine that an asynchronous HTTP-client would have to perform
The one feature I like about the AHC client that appears to be missing
here is the higher-level abstraction of an HTTP request. The one
drawback of doing everything with URLs is the requirement that the user
of the client needs to be responsible for encoding all of the parameter
information
Btw, what was the status of DNS resolution in MINA? I remember that at
some point DNS resolving used the blocking java API calls. I could
imagine that an asynchronous HTTP-client would have to perform a lot of
DNS queries(or not, depending on use). Could this become a pithole?
-Eero
Rick
I posted some use cases here:
http://cwiki.apache.org/confluence/display/AWEB/ClientUseCases They
still need some refinement to properly convey what I want but they're a
decent start.
I've also posted a hypothetical AsyncWeb Client API at
http://swamp.homelinux.net/mina/asyncweb/client/api/ with
25 matches
Mail list logo
