On Thu, 2013-06-06 at 12:17 -0400, Nathaniel McCallum wrote:
I agree. And I wrote it. :(
I can sympathise with that :)
Unfortunately, the JS interpreter can't disappear. WPAD is *very*
widely
deployed and requires it. We can mitigate it by stuffing it in a session
daemon.
Yes, which is what pacrunner already does.
TBH I don't really *care* how it's implemented. Only that it *is*
implemented, and all apps use it by default.
The libproxy.so.1 API is enough for now, I think.
In general however, I don't want us to have multiple
choices between incomplete implementations.
Well, it's not "incomplete implementations' in the sense that some have
one API and some have another, or don't implement certain features. They
both have the same basic API and they just get their answers by
different methods. But that's true of libproxy itself on multiple
platforms, or even when it's just configured with different plugins.
Let's either fix libproxy or make something like pacrunner
multiplatform.
Well, perhaps we should make libproxy *query* pacrunner, but not use
pacrunner's libproxy replacement. That's "just another information
source" for libproxy, but the patch has been languishing for years
without being applied.
http://code.google.com/p/libproxy/issues/detail?id=152
I think the existing libproxy API is sane enough. The only problem is
that it's 'tainted' with the idea that it's slow and might even load
multiple JS engines within one process... hence the horridness in glib's
networking support to do its own pacrunner-style thing (but badly), and
reticence elsewhere about using it.
--
dwmw2