That would also suffice. If possible, I would prefer to pass an implementation of the interface in to HttpConnection upon creation rather than have it as a global setting, but I presume that's easier anyway.
I'm not exactly sure how it would get implemented but it could be on a per connection basis. It would not have to be global. It will really just depend if we can do it without too many API changes.
One other thing is that, currently, as a side-effect of using the Socket(DNS name, ...) constructor, the DNS lookup and Socket connection processes seem to be rolled into one. I was wondering if it is worthwhile setting a separate timeout for DNS lookup? As it stands, if DNS becomes slow for some reason then, even if the remote server is responding quickly, you'll get exceptions. Most people wouldn't care, but it would be nice to be able to set a longer timout for DNS responses if you happened to know they sometimes take a while. This would also allow some leeway for an implementation of this DNS interface to do retries internally without worrying about a `connection' timeout externally.
Interesting, not something I had thought of. This could certainly be done if we were using a pluggable DNS resolution method.
Mike
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
