Re: [announce] gnome-proxy

[Nathaniel McCallum <nathaniel natemccallum com>]

On Thu, 2007-01-18 at 10:22 +0100, Alexander Larsson wrote:
> On Wed, 2007-01-17 at 23:05 -0500, Nathaniel McCallum wrote:
> > I'd like to announce a proof-of-concept I've been working on and
> > hopefully get some feedback/help moving forward.
> > 
> > gnome-proxy (http://code.google.com/p/gnome-proxy/) is a replacement for
> > gnome-network-preferences with the following added features:
> >   * Per-network proxy settings (via NetworkManager)
> >   * Support for the widely deployed WPAD and PAC non-specs
> >   * Easy D-Bus API providing optional (soft) dependency
> >   * Automatic profile switching (via NetworkManager)
> >   * The goal of JustWorks (no manual proxy configuration/switching)
> > 
> > gnome-proxy-daemon is a user-session daemon that provides the D-Bus
> > method org.gnome.Proxy.getProxy(url).  All the details of proxy settings
> > are hidden behind that D-Bus call.  Applications would no longer need to
> > correctly parse various gconf keys, but just simply call one method.
> > Additionally this handles NetworkManager network-switching as well as
> > auto-updating the old gconf keys for backwards compatibility with
> > gnome-network-preferences.
> 
> My main worry is performance. Each access to a url would need an out of
> process call to a possibly contended daemon. Say you're listing a folder
> with 2000 files in nautilus. Thats at least 2000 out of process calls
> (stat for each file), and likely a lot more for thumbnailing and other
> details.
> 
> And we pay this penalty even in the "no proxy configured" case, because
> there is no way for the client to know there is no proxy configured atm.
> 
> I don't think any API as simple as this is viable, at least for use for
> e.g. gnome-vfs. There has to be a way to be able to cache the results of
> proxy lookups.


I agree, it sucks.  For the PAC/WPAD case, I don't really see any way
around it.  We could expose the url of the PAC in the D-Bus API and
allow applications to code their own PAC handling, but I don't know that
it gives us that much benefit.

For the "no proxy configured" or the "manual proxy configured" cases, we
would want the app to cache the results.  getProxy() could return a
boolean "cacheable" field.  If set to true, the app will not call
getProxy() again until a "ProxySettingsChanged" signal is emitted. In
that case, WPAD/PAC would always return cacheable == false and
manual/none would always return cacheable == true.

A lot of this comes from the fact that PAC/WPAD are completely and utter
crack and, while I would love to just ignore them, they are *widely*
deployed.

Thoughts?

Nathaniel