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
<<attachment: smime.p7s>>
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
