Comment 118 for bug 304889

@Nicolas

> But the fact is that this method had never worked.

Grep for "pidgin" in this thread. That method works. In fact, it's the only one that does. That's why this bug exists and people are annoyed; the default IM client used to work (Pidgin), now it doesn't (Empathy).

What I would have done is write something that works, like your code for socks and http proxies, and make it a library, or just copy it inside the most popular CM's (gabble and butterfly) with a git submodule. This way you wouldn't be relying on GLib slowness/stubbornness. Once GLib has proper proxy support, you switch. Problem solved.

The next problem is configurability. Instead of relying _completely_ on libproxy, I would allow the option to override the proxy configuration with a CM property, this way even if libproxy is buggy (which it is), the user would not be stuck. I would have also added the option to read directly from GConf, and let the user be able to choose this option.

> so I took the long road

With my proposal you have the benefit of both. When libproxy/GIO are truly ready, you can switch easily, and everyone benefits. In the meantime, things would work, and this bug would be solved.

> having to update things into distribution to get things to work is completely
> normal

Normal for GNOME people. Other people would rather have something working _right now_, even it's not exactly the mode ideal, generic, extensible, and permanent way of doing things. Hint: Pidgin, XChat, Firefox, Ekiga, etc.

> But the reality is that HTTP Connect users represent probably less then 1% of the users

Ha! I would like to see proof of that. How about people following this bug mention what type of proxy support they need? (socks, http, etc.) It's important because Nicolas is assuming _everyone_ is using SOCKS, and that is reflected on how libproxy interprets GNOME network configuration.

> What Felipe is confusing in his comment is the support for proxy in Telepathy
> against bugs in the libproxy implementation.

Take a look at the title of this bug: use *system* proxy settings. This means GConf, and this means precisely libproxy. If libproxy returns "socks", when the user is expecting "http" (which it does), then the user wouldn't be able to connect, and this bug remains valid.

> We are working hard to make it possible to trigger this choice in libproxy
> without the risk of reducing your connectivity

What you don't seem to understand is that the connectivity is *zero*, you cannot reduce that, even if you try. Note that libproxy is not used by anything in Unbuntu, so it doesn't matter what you do there, it would not affect anyone negatively. The problem is this GNOME mentality, that everything must be perfect since day 0, and therefore it's OK if things don't work at all before that, which is the current situation.

> Felipe also often ignore the miss-adapted configuration tool we have in Gnome.

Works in Pidgin.

Now, I would not like to give the impression that everything is horrible. There is great progress thanks to the efforts of many people, specially Nicolas; we are getting closer and closer to the generic solution, and I certainly would like to contribute to these efforts, when time allows. However, I would like something that works _right now_, and I think everyone here agrees.

So, for me, I'm looking into various solutions that are not "perfect" but should get the job done (any of them):

 a) By default install only telepathy-haze (no gabble, idle, butterfly, etc.)
 b) Update to libproxy 0.4.6 and apply a patch so it's possible to return both "http" and "socks" for _all_ protocols (msn, xmpp, irc, etc.)

I don't think any other option has any chance of making it for the next Ubuntu release.

Also, I would like to correct my previous statement that MSN would not work. It does seem that the latest telepathy-butterfly has the option to override whatever libproxy is passing, so it's possible to get it working. However, that would not resolve this bug.

Cheers.