Just to throw it back in the mix of ideas,<div><br></div><div>The http code that I use in my http-based prpls already uses libpurple eventloop, Dns and proxy settings :)<span></span><br><br>On Friday, 5 October 2012, Daniel Atallah  wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Oct 4, 2012 at 9:36 AM, Tomasz Wasilczyk<br>
<<a href="javascript:;" onclick="_e(event, 'cvml', 'tomkiewicz.groups@gmail.com')">tomkiewicz.groups@gmail.com</a>> wrote:<br>
> I would like to do a little summary of our discussion.<br>
><br>
> 1. Libsoup seems not to be acceptable, because of (probably) inability<br>
> to fit into purple event loop.<br>
><br>
> 2. "Wrapping the world" would be elegant solution, but providing<br>
> half-naked curl interface for advanced features is lesser of two<br>
> evils.<br>
><br>
> 3. We would like to leave some "simple" api for simple requests, but<br>
> not identical to current one (emulating current behavior in curl would<br>
> be hard to accomplish).<br>
><br>
> 4. Proxy support: is it acceptable, to set up proxy via CURLOPT_PROXY<br>
> instead of using our socket creation functions? With<br>
> CURLPROXY_SOCKS5_HOSTNAME used for TOR proxies.<br>
<br>
I think it's suboptimal; not sure about unacceptable - my guess is<br>
that it's almost certainly going to be the case that the proxy<br>
functionality will be different if curl handles the proxies itself<br>
than if it uses the libpurple code.  It's been my experience that<br>
proxies tend to be very quirky and particular and that a change like<br>
this will cause probably cause breakage.<br>
On the other hand, maybe the curl proxy code is more robust than the<br>
libpurple proxy code, so perhaps it would just work better.<br>
<br>
Note that with the current libpurple behavior, the hostname is always<br>
passed to the SOCKS5 proxy - there is even a flag to do so with SOCKS4<br>
(which technically doesn't support doing that) (just as a FYI).  Tor<br>
isn't an issue here (as long as curl actually honors the proxy<br>
settings).<br>
<br>
> 5. SSL support: is it acceptable, to inject our certificates to curl<br>
> configuration, instead of using our ssl implementation?<br>
<br>
I'm not sure that this is going to be possible to make work right -<br>
how would this deal with prompting for unrecognized and expired certs?<br>
<br>
This raises another set of questions; it looks like curl can use one<br>
of 8(?!) SSL backends, not all of which have a GPL compatible license.<br>
 Assuming that the license isn't a problem (which I'm not really sure<br>
about), this is introducing another potential opportunity for<br>
incompatibility (historically there have been issues with certain<br>
sites and SSL implementations, the most recent that I'm aware of being<br>
the NSS issue mentioned on<br>
<a href="http://sourceforge.net/apps/mediawiki/sipe/index.php?title=FAQ" target="_blank">http://sourceforge.net/apps/mediawiki/sipe/index.php?title=FAQ</a>).<br>
<br>
><br>
> 6. DNS: do we have to serve them on our own? As far, as I understood,<br>
> it was most important when using SOCKS/TOR proxy (see 4).<br>
<br>
This is perhaps the most important issue IMO.  In addition to the Tor<br>
stuff blocking DNS from happening, there are several other issues.<br>
 * libpurple has a pluggable DNS API - it's important that DNS is done<br>
though that API for some libpurple clients (e.g. instantbird IIRC).<br>
 * It's not possible to do HTTP purely based on IP addresses - the<br>
hostname is important to the protocol, so we can't resolve before<br>
interacting with libcurl.<br>
 * Redirects are problematic unless we make libcurl not handle<br>
redirects itself and handle those in libpurple (which I think would<br>
necessitate "wrapping the world" and banning direct libcurl usage<br>
(which may be hard to enforce)).<br>
<br>
> Did I missed something?<br>
><br>
> Forcing http library to use our socket creation functions is rational,<br>
> when using all of it's benefits (proxy, ssl, dns). It seems, that none<br>
> of popular libraries supports providing callbacks for all of them. So,<br>
> I suggest using solutions mentioned above.<br>
<br>
I guess I don't see real solutions, just partial workarounds.<br>
<br>
Conceptually, I'm all for a HTTP library - ideally speaking HTTP isn't<br>
something we'd do ourselves, however it doesn't look like libcurl<br>
really fits the requirements libpurple has for such a library.<br>
<br>
What is it that we specifically want/need that libcurl will provide?<br>
<br>
Is there another option for a library?<br>
<br>
-D<br>
<br>
_______________________________________________<br>
Devel mailing list<br>
<a href="javascript:;" onclick="_e(event, 'cvml', 'Devel@pidgin.im')">Devel@pidgin.im</a><br>
<a href="http://pidgin.im/cgi-bin/mailman/listinfo/devel" target="_blank">http://pidgin.im/cgi-bin/mailman/listinfo/devel</a><br>
</blockquote></div>