cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: ares / c-ares TODO?

From: codemastr <codemstr_at_ptd.net>
Date: Sat, 31 Jan 2004 13:14:32 -0500

> Is there anything anyone wants to see included or fixed before I proceed
with
> this?
I assume you've added that guy's (sorry, forgot his name) non-blocking
fixes? If so, then I think it's good.

> I've added a function named ares_version() that I plan to use from libcurl
> soon, to be able to display what ares version that is being used. That
will
> then make us completely incompatible with the original ares library. Any
> objections against this plan?
I have no problems with it. I force my users to get c-ares anyway. I think
it's a good idea anyway since somewhere down the line someone is going to
add IPv6 support and then we'll ruin support for ares anyway. Might as well
force people to switch now rather than wait until they have to.

> Can anyone forsee any problems with us remaining with the prefix 'ares' to
all
> symbol names or should we rename them?
Well no system is going to have ares_* in the libc so the only time we'll
have namespace pollution is if someone purposely includes ares as well,
which I don't forsee anyone doing. Furthermore, since c-ares already has
fixes to ares, and Win32 support, and as I said in the future IPv6 support
(and probably other new features like the nsswitch.conf stuff), my guess
would be that many people currently using ares would likely switch to c-ares
(perhaps c-ares should be on freshmeat and what not listed as a continuation
of the ares project?). Therefore, leaving it as ares_* would make porting
easier for them. If you do want to change it to cares_* then I'd suggest
adding a new header file something like arescompat.h which includes a bunch
of #define's to map the cares_* to the ares_* so people using ares can
easily port it over.

> Is there anyone who objects to us discussing c-ares here, or should we
> consider moving this talk over to a separate mailing list? It certainly
isn't
> strictly libcurl-related.
Well no one complained about me asking about the URL parsing libraries, so I
guess no one will complain about this :) I think c-ares is related enough to
libcurl to have it here. Otherwise it'd result in a bunch of forwarded
messages. I.e. someone reports a bug with libcurl that actually turns out to
be a bug in c-ares so you have to forward it over to that list and vice
versa.

Dominick Meglio

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
Received on 2004-01-31