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.)
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.
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.
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.
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.
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.
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).
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.
S
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e7b6f16.9020...@mikemestnik.net
