Comment 2 for bug 929207

Hi Martin, thanks a lot for your input.

> * Does this change the code path/structure for situations where users use no proxies? I. e. will the "no proxy" case also have a new process and use the same code path? In other words, what's the regression potential for the "no proxy" case?

When the user has not configured a proxy then the tunnel process will not be started, so it will still use the same code path as before. (The only new code that will be run in that case is the checking for the config)

> * Why do we need a separate process for this tunneling? It sounds rather heavy (memory usage, wakeups, startup time, etc.) to have yet another long-running Python process in the system for protocol translation, these can usually happen in-process.

We have settled on QtNetwork to provide consistent proxy support for every Ubuntu One process, since we ran a small survey[1] with our users, and we found out that they wanted to use a number of proxy protocols and proxy authentication schemes, and in our research this was the library that supported the best variety.

The Ubuntu One syncdaemon uses a twisted reactor as the mainloop, and to integrate with QtNetwork it needs a specialized reactor that can be integrated with QtCore. ATM, the only twisted reactor that integrates with the Qt mainloop is the qt4reactor which is currently available in universe. We could file a MIR to use it from ubuntuone-client, but we prefer not to do that at this point since there is no clear intent from upstream to maintain it, and the U1 team does not have (yet) the expertise nor are able to commit to maintain it.

[1] http://blog.protocultura.net/post/12660278531/u1-proxy-support

> * Where does it get the proxy configuration from? Do you use libproxy? There are quite a few places where proxies are configured (/etc/environment, GNOME control center, Firefox etc.).

The proxy configuration is taken from gsettings, so the way to set them is with the GNOME control center.