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 pithole?
That's a very good point, Eero. I think blocking DNS lookups could definitely be a very big pit hole. Did anything ever come from all the asynchronous DNS lookup discussions? And that's not the only DNS issue. If a DNS returns multiple A records for a given host name, most browsers will try to connect to the IP address from the first A record. If that fails, they'll try the next IP address and so on until the connection succeeds or all of the A records have been exhausted. We should support this same behavior in AsyncWeb. -Mike > > -Eero > > 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 encoding all of the >> parameter information in the URL. In the AHC approach, a request is >> configured as an operation to a particular address and additional >> specifics of the operation are attached to the request (parameters, >> credentials needed for authentication, proxy configuration etc.). The >> AHC client then uses that information to handle the URL encoding, >> authentication challenges, proxy connection, etc. There are times >> where a straighforward "fetch me this URL mode" is sufficient. There >> are other situations where that becomes awkward to use. >> >> Rick >> >> 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 also posted a hypothetical AsyncWeb Client API at >>> http://swamp.homelinux.net/mina/asyncweb/client/api/ with the intent to >>> further promote discussion and foster more innovative ideas. I would >>> love to here some feedback on this API. What do you like, dislike, not >>> understand? Where do you see room for improvement? The API is really >>> rough in places but for the most part it conveys the ideas I've had over >>> the past week or so. Any suggestions for name changes to classes and/or >>> methods are welcome. >>> >>> -Mike >>> >>> >> > >
