On Fri, Sep 14, 2007 at 04:13:50PM -0700, Alexey Pesternikov wrote:
> I pointed that in one of my previous posts in the thread. The problem is
> Curl_addrinfo depends on configuration built at compile time, and the
> configuration is unavailable in runtime header ( curl.h), which is right thing.
> Otherwise it would make an unstable binary API.

There are lots of #ifdefs in curl.h already; this could be done has just one
more. Or, we could resurrect Daniel's suggestion from some ago to supply a
/usr/include/curl/curl_config.h with the contents of config.h but renamed
with a CURL_ or similar prefix.

> That would make the code simpler and semantics cleaner, but breaks
> compatibility. The man page clearly states: A non-zero return code from the
> callback function will signal an unrecoverable error to the library and it will
> close the socket and return CURLE_COULDNT_CONNECT. (Option added in 7.15.6.)
> I will think twise before upgrading in the future if you guys take a
> compatibility issues so easy :)

Good point--I assumed it was documented to allow a 0 or 1 to be returned. The
new semantics could be enabled with a curl_easy_setopt, but that's starting
to get complicated.

> what about providing a way for the callback
> function to provide its own open and connected socket for libcurl to use
> instead of the one libcurl wants? Is that overloading this poor callback
> function too much?
>
> We already overloaded it to the point of making the callback name misleading.

Plus, it's a bit unclean--a socket would be created then immediately
destroyed in such a case. Maybe it's not such a good idea.

>>> Dan

-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved