On Fri, Sep 14, 2007 at 01:30:03PM -0700, Alexey Pesternikov wrote:
> As soon as nobody concerned here is the new version. It uses modified
> curl_sockopt_callback.
> The calback can modify or refuse (by returning ) the address.

Dont' forget to update the documentation accordingly.

> typedef int (*curl_sockopt_callback)(void *clientp,
> curl_socket_t curlfd,
> - curlsocktype purpose);
> + curlsocktype purpose,
> + int* ai_family,
> + int* ai_socktype,
> + int* ai_protocol,
> + struct sockaddr *ai_addr,
> + socklen_t* ai_addrlen);

Rather than passing these parameters individually, why not pass
a pointer to a Curl_addrinfo? It would also need to be made public and
therefore placed into curl/curl.h, which might be a bit tricky. In most
cases it will end up being a typedef of the system's struct addrinfo, though.

My only other comment has to do with the semantics of the curl_sockopt_callback
return code. Right now, libcurl will always bail if a nonzero is
returned, i.e. an error, but if zero is returned, it will sometimes continue
and sometimes redo the callback after reopening the socket (if the address
family is detected to have changed). It seems somehow cleaner to me to
have the callback make the determination as to whether it should close
and reopen the socket (and call be called again), by returning a code
other than 0 or 1.

And since we're overloading the curl_sockopt_callback anyway and opening and
closing sockets several times, 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?

>>> Dan

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