/pidgin/main: e6c37a5e6666: New dependency: libcurl
eion at robbmob.com
Sat Oct 6 00:44:28 EDT 2012
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
> > 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
> > 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
> > 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?
> Devel mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Devel