/pidgin/main: e6c37a5e6666: New dependency: libcurl

[Ethan Blanton]

Tomasz Wasilczyk spake unto us the following wisdom:
> - libcurl perfectly fits into purple event loop (see my
> implementation); libsoup doesn't seems to provide such possibility,
> but there is a way to swich GMainContext. However, I still don't know,
> how to get it working with libpurple

This is an important question to answer if we really care about
libsoup.  I'm not (personally) sure it's worth the effort.  Perhaps
Eion can weigh in with why he thinks we should bother with libsoup (or
anyone else who agrees, I just know he's mentioned it).

> - libcurl doesn't provide any callbacks to SSL verifying functions.
> Although, it provides CURLOPT_CAINFO, CURLOPT_ISSUERCERT,
> CURLOPT_CAPATH, which can allow us to inject our internally setup
> certs

I don't know enough about our current CA handling to know if this is
viable.  I think we manually merge multiple CA dirs, right?

> - libcurl provides callback function for creating a socket, but it
> have to return socket fd at once (libpurple returns estabilished
> connection within a callback) AND it gets only ip addresses to connect
> to (don't get http proxy benefits with passing an url). However, it
> supports all proxies, that libpurple supports (see CURLOPT_PROXYTYPE)
> - we can just inject it

There are a couple of things to watch, here.  First off, requiring
synchronous connect is bad, because it means libcurl is doing
synchronous DNS lookup followed by connect(), which can stall the UI.
We really want to avoid that if we can.  Second, we're a bit pickier
about some of the proxy types than libcurl is; for example, we
restrict DNS to activities that we can pass through a SOCKS 5 remote
lookup when we use the Tor proxy type, to avoid leaking information
onto the local network about Tor-sheltered activity.

> - I think, libcurl may be hacked to operate on "faked" sockets, to
> force it using our socket creating function (proxy api), but I think
> it may lead to more problems than it solves. See
> CURLOPT_WRITEFUNCTION, CURL_WRITEFUNC_PAUSE, CURLOPT_READFUNCTION,
> CURLOPT_OPENSOCKETFUNCTION (this one could return our "faked" socket
> identifier instead of real socket).

Can we use *real* sockets here?  I assume the problem is that the open
socket function has to return a "real" fd in that case, and we don't
have one...  Once our sockets are open, though, curl can use normal
read()/write()/etc. on them.  That is, assuming it understands
SO_NONBLOCK sockets.

> - I don't see any possibility to inject our DNS resolver functions to
> libcurl

:-(

> Another thought about totally wrapping http library into our
> abstraction: there is really a lot to wrap. Also, if we don't wrap
> _everything_ we should to and make an option to provide user-specified
> http plugin for libpurple (I mean: we make plugin side also a part of
> API), there may be a necessity to wait for libpurple 4.0.0 to
> introduce such new features (require them from such http support
> plugins).

I don't think this is necessary (wrapping everything).  However, if it
is, and we want to provide a http plugin interface similar to our SSL
plugin interface, this can go into 3.0.0 without problem.  We haven't
frozen that API.

Ethan