Comment 117 for bug 304889

When I first started working on proxy in Telepathy there was two ways this could be fixed. The quick way would have been to implement it in every single network oriented application. To do so you just have to find another project that match licence, copy paste some code do basic testing and your done. But the fact is that this method had never worked. The big portrait is that every software interpret the configuration differently (mainly due to ambiguities in the configuration) or has incomplete implementation.

I was bored of that, so I took the long road, that one that can benefit all and eventually ensure that network oriented application don't have to care about proxy since it will just work. This road is to get proxy support to be handled by libraries like GIO and libproxy. In contrast to what Felipe says, having to update things into distribution to get things to work is completely normal, and takes time. We can't implement features in already existing versions and we can't maintain hundreds of different branches of every projects so the distro does not have to update.

Getting this in the next Ubuntu release has nothing to do about doubt, it's about priority. If 100% of the targeted users where using HTTP Connect proxy, all this would be updated much faster. But the reality is that HTTP Connect users represent probably less then 1% of the users, I don't think it's enough people to justified the risk and the energy required to get those new features in so quickly. What you should do instead if you have the knowledge and time is to test those things, discuss and report precise bugs and create testimonial for distro that says it's working.

Finally, Telepathy Butterfly (the MSN backend) has full HTTP/HTTP Connect/SOCKS support. I don't know where Felipe got that it does not work for MSN because it works very well.

What Felipe is confusing in his comment is the support for proxy in Telepathy against bugs in the libproxy implementation. Yes HTTP Connect is considered an unsafe choice in libproxy. HTTP Connect server (the commercial ones) has a large reputation of implementing filters and port blocking that usually reduces your connectivity. We are working hard to make it possible to trigger this choice in libproxy without the risk of reducing your connectivity, but we have hit an internal design issue that needs more time.

Felipe also often ignore the miss-adapted configuration tool we have in Gnome. This tool, based on old Netscape Navigator configuration, is undocumented and present ambiguities. On this, some people also have long term solution like a new storage for GSettings/GConf or even an integration with software like NetworkManager or ConnMan. But let me reassure you that as soon as the previously mentioned bug in libproxy is fixed, I'm also going forward with shorter term fixes that should make it work better.