/pidgin/main: e6c37a5e6666: New dependency: libcurl

[Daniel Atallah]

On Thu, Oct 4, 2012 at 9:36 AM, Tomasz Wasilczyk
<tomkiewicz.groups at gmail.com> wrote:
> I would like to do a little summary of our discussion.
>
> 1. Libsoup seems not to be acceptable, because of (probably) inability
> to fit into purple event loop.
>
> 2. "Wrapping the world" would be elegant solution, but providing
> half-naked curl interface for advanced features is lesser of two
> evils.
>
> 3. We would like to leave some "simple" api for simple requests, but
> not identical to current one (emulating current behavior in curl would
> be hard to accomplish).
>
> 4. Proxy support: is it acceptable, to set up proxy via CURLOPT_PROXY
> instead of using our socket creation functions? With
> CURLPROXY_SOCKS5_HOSTNAME used for TOR proxies.

I think it's suboptimal; not sure about unacceptable - my guess is
that it's almost certainly going to be the case that the proxy
functionality will be different if curl handles the proxies itself
than if it uses the libpurple code.  It's been my experience that
proxies tend to be very quirky and particular and that a change like
this will cause probably cause breakage.
On the other hand, maybe the curl proxy code is more robust than the
libpurple proxy code, so perhaps it would just work better.

Note that with the current libpurple behavior, the hostname is always
passed to the SOCKS5 proxy - there is even a flag to do so with SOCKS4
(which technically doesn't support doing that) (just as a FYI).  Tor
isn't an issue here (as long as curl actually honors the proxy
settings).

> 5. SSL support: is it acceptable, to inject our certificates to curl
> configuration, instead of using our ssl implementation?

I'm not sure that this is going to be possible to make work right -
how would this deal with prompting for unrecognized and expired certs?

This raises another set of questions; it looks like curl can use one
of 8(?!) SSL backends, not all of which have a GPL compatible license.
 Assuming that the license isn't a problem (which I'm not really sure
about), this is introducing another potential opportunity for
incompatibility (historically there have been issues with certain
sites and SSL implementations, the most recent that I'm aware of being
the NSS issue mentioned on
http://sourceforge.net/apps/mediawiki/sipe/index.php?title=FAQ).

>
> 6. DNS: do we have to serve them on our own? As far, as I understood,
> it was most important when using SOCKS/TOR proxy (see 4).

This is perhaps the most important issue IMO.  In addition to the Tor
stuff blocking DNS from happening, there are several other issues.
 * libpurple has a pluggable DNS API - it's important that DNS is done
though that API for some libpurple clients (e.g. instantbird IIRC).
 * It's not possible to do HTTP purely based on IP addresses - the
hostname is important to the protocol, so we can't resolve before
interacting with libcurl.
 * Redirects are problematic unless we make libcurl not handle
redirects itself and handle those in libpurple (which I think would
necessitate "wrapping the world" and banning direct libcurl usage
(which may be hard to enforce)).

> Did I missed something?
>
> Forcing http library to use our socket creation functions is rational,
> when using all of it's benefits (proxy, ssl, dns). It seems, that none
> of popular libraries supports providing callbacks for all of them. So,
> I suggest using solutions mentioned above.

I guess I don't see real solutions, just partial workarounds.

Conceptually, I'm all for a HTTP library - ideally speaking HTTP isn't
something we'd do ourselves, however it doesn't look like libcurl
really fits the requirements libpurple has for such a library.

What is it that we specifically want/need that libcurl will provide?

Is there another option for a library?

-D