On 9/14/07, Dan Fandrich <dan_at_coneharvesters.com> wrote:
>
> 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.

I don't like to reinvent the wheel, especially in project I don't know in
details.

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.

Good idea. Currently there is no such file, so I have to stick with that
ugly parameters.

> 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.
>
I see nothing wrong in that.

Alexey,
http://page2rss.com RSS feed from almost any page
Received on 2007-09-15