/pidgin/main: e6c37a5e6666: New dependency: libcurl

[Eion Robb]

Just to throw it back in the mix of ideas,

The http code that I use in my http-based prpls already uses libpurple
eventloop, Dns and proxy settings :)

On Friday, 5 October 2012, Daniel Atallah wrote:

> On Thu, Oct 4, 2012 at 9:36 AM, Tomasz Wasilczyk
> <tomkiewicz.groups at gmail.com <javascript:;>> 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
>
> _______________________________________________
> Devel mailing list
> Devel at pidgin.im <javascript:;>
> http://pidgin.im/cgi-bin/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20121006/b56c8842/attachment-0002.html>