This is the kind of information I'd intend to propagate and turn into release goals. Understanding that there's more then one way... Debian may need a centralised configuration where all of the deployed back-ends(GSocketClient/Qt/other:apt:wget:axel) would be configured.On Wed, 21 Sep 2011 at 14:13:31 -0500, Mike Mestnik wrote:I'd like to start a movement to verify and assist projects/packages with the proper deployment of software that supports proxies.In GLib-based applications, connecting using GSocketClient while having glib-networking installed will automatically use a configured proxy; this is much less ongoing maintenance burden than adding specific proxy support to every networked application, so please use this route where feasible in GLib/GNOME applications, rather than repeatedly writing app-specific proxy code. Recent versions of telepathy-gabble (as used by Empathy for XMPP) will automatically pick up GNOME/KDE proxy settings in this way, for instance. (There's probably an equivalent thing I could say about Qt/KDE applications, if I knew Qt better.)
Let me make myself clear, "I fully support and advocate using centralised librarys, especially when they implement tasks common to many applications."
However the real work is a little different then that Utopia. I belive that leeway should be given in the short term for things that are deemed important. I belever that proxy support is so important.
Well, I'll say one thing. I'm a little bit retarded so forgive me as there should be some one other then me doing PR(I rather like Paul Wise's comments, nice work... Don't take that the wrong way I understand you don't have the time.) anything I'm involved in. I understand that the following point of view is likely to be overkill, however if no-one is willing to stake a flag down in there utopia then any line drawn could be misplaced.What I need most of all is community support, it's no good to confront developers or package maintainers that are insistent on rebelling against the use of proxies.There's an important difference between "I think proxies don't matter" and "I think this particular patch to support use of proxies is more maintenance burden than it's worth"; be careful not to mistake the second for the first. Part of a maintainer's job is to say "no" to things they're not going to be able to maintain in future.
If an application, any application, lacks proxy support and a patch exists that's five lines enabling environment variables then in the absence of any other patch it should be...
A. Disabled by default, but compiled in at least one package.There is no point in fighting about the better way if the person advocating the better way is not willing or able to do anything more then put pen to paper. Either write a better patch or get out of the way of progress.
I can't understand why this "I don't like it." attitude would ever fly. There are plenty of ways to guard against new code from causing problems... For example "Disabled by default" could mean that the code is only executed when a new command line flag is present. The dev. can put a patch on top of the submitted patch to ensure any level of disabling they are comfortable with. There is even a possibility to split the proxy support out into another binary package if it's the only way to work around technical issues.
This "It might not work attitude" is worthless if it is working and I assure you that proxy support is nothing to cry weapons of mass destruction over. It's completely harmless, even if done improperly. *Beyond the average rate of failure for any additional patch.
Again, if you want it done right then you'll just have to do it yourself. When it's a this is un-usable in a given environment there just needs to be a solution, instead of excuses.I for one would tend to reject a patch to add a "full" proxy implementation to any network application that I maintained, but I'd be more likely to accept a patch that used GProxyResolver or g_socket_client_add_application_proxy (for GLib code) or something like libproxy or pacrunner (for non-GLib code).
S