Hey people [Warning, long message following!]

I've managed to successfully run a few test cases while using ares for
asynchronous name resolves. (I still need to make sure 100% runs fine, and
then I need to make a build without ares again to see that it still runs 100%
like that too.)

There are a few discussion points embedded in this status report. I'm awaiting
your views and ideas.

1. easy interface
=================

The biggest impact from this when using the easy interface, is that we can
implement perfectly fine timeouts without using signals. This is of benefit
for all, but especially libcurl on non-unix platforms and for unix-
applications that run libcurl multi-threaded (as signals usually don't mix
very good with threads).

2. multi interface
==================

This is of course the big winner here. This change should remove the last
reason that curl_multi_perform() could previously block for a longer while.
Now, multiple connections can all get their host names resolved
simultaneously.

I say "should" here, since there are still a few places in the code that I
decided I'll make curl_multi_perform() block until the name is resolved, just
because it is tricky to fix all the issues and I figured that I better fix the
major ones first and leave the others to fix later on.

2.1 multi API addition
----------------------

We might need to extend the multi API with one function that we're missing
today, that I think will improve things when we use asynchronous name
resolves. ares has a function named ares_timeout() that returns a struct
timeval pointer suitable for use in the applicaton's select() call to make
sure the application doesn't wait too long until the next library call is
made. This is of course a requirement to be able to rend re-tries to the DNS
server(s) when suitable. It works like this:

   struct timeval *ares_timeout([ares handle],
                                struct timeval *maxtv,
                                struct timeval *tvbuf);

... and I think we need a function to give this functionality to the app, and
I suggest that we make/name it:

   struct timeval *curl_multi_timeout([multi handle],
                                      struct timeval *maxtv,
                                      struct timeval *tvbuf);

3. async lib
============

ares is the library I've used to add this functionality. It is written by Greg
Hudson and is available from download here:
ftp://athena-dist.mit.edu/pub/ATHENA/ares/ares-1.1.1.tar.gz

3.1 Alternatives/hooks
----------------------

Previously when we've talked about asynch name resolves, people have mentioned
adns and other asynchronous libraries that are using a license that are either
GPL very similar to GPL. When I've expressed my disklike for those, people
have mentioned that we could add "hooks" in the code that would allow a 3rd
party asynch library to be used.

I don't know if anyone cares about this, once asynch works based on ares, but
I have not bothered to work on any such system. That work is still ahead of
anyone who feels ares is not the correct lib to depend upon.

3.1 ares build
--------------

Are we to consider ares such an essential piece of curl/libcurl that we
include it fully in the archives, or should we require people to download and
build it separately and just use configure switches to enable its use (as we
do with OpenSSL and zlib etc)?

This also relies on the issues below.

3.2 ares portability
--------------------

I want the highest possibly degree of portability on ares, so that we can
experiece the power of this on as many platforms as possible. On those
platforms that ares really can't be made to work, we will use the current
synchronous resolve code.

Greg Hudson, maintainer of ares, replied to Christopher R. Palmer's mail about
their win32 patch and rejected to apply it on his main sources. While I agree
that it could be made in a less intrusive manner (I'll reply in a separate
thread later on how I think we could fix the win32 patch to get smoother
imported and less #ifdef filled and thus ) it may give us a signal here.
If we can't get a patch that is good enough for Greg to accept into his source
tree, then we need to fork ares and apply the patches we think are fit. Still,
this is not a step I take lightly on or that I want to do. I think that would
put us in an unfortunate position.

3.3 ares maintaining
--------------------

Since we need to get patches applied to ares to make it build fine on win32
and the Mac OS X fix previously mentioned, we depend on Greg to apply them and
make new archives available or we host them or the patches only ourselves.

I'm pretty much leaning towards importing ares into the curl source tree, in
its own directory and apply patches and make it build etc. I'll then make sure
we offer all changes upstream to Greg Hudson and discuss with him on the test
approach to get the necessary changes in.

Please ventilate your views on any of the above mention subjects, agree or
disagree, I need feedback.

-- 
 Daniel Stenberg -- curl: been grokking URLs since 1998
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01