On Sat, 29 Jul 2006, Yang Tse wrote:

> The problem is that memdebug.needs to be the last header included, so any
> new symbol defined in memdebug.h should not be visible by c-ares headers. As
> a matter of fact we might want the opposite, make memdebug.h pull only the
> absolute needed minimum of libcurl when being used from c-ares.

Oh right, that would of course work nicely too.

>> We might move away the c-ares CVS repo from the curl one in the future and
>> we must not add "hard" connections between them that aren't allowed to
>> deviate.
>
> It seems I had the wrong impression that it was the opposite way, and that
> some day c-ares could be fully merged into libcurl's codebase.

I'm a bit undecisive on how to proceed on this.

On one hand I would love to both simplify the name resolving in libcurl and
have the greatest possible feature-set, which would mean always using c-ares
for all platforms for ipv4 and for ipv6 environments. I believe we're close to
actually being able to do this with Gisle's recent
resolve-with-c-ares-using-ipv6 work, although I haven't an exact picture of
the situation.

On the other hand, c-ares is a separate project and it is being used by at
least a handful of other projects and I'm already having troubles to keep the
maintaining and work on c-ares at a fair level. If I decide to hand over the
maintainership and step down from my chair in that project I can't see how I
can force the CVS repo to remain a subdir of curl's. Of course the question is
if libcurl benefits from having c-ares as a separate project or if it would
benefit from having c-ares a more tightened relationship and simply an
integrated part of the lib. I don't think I have an answer to that myself.

> Do we have any numbers or feedback about the use of stand alone c-ares
> without libcurl ?

No, but then I don't even have numbers for (lib)curl. Just guesses.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html