On 11 April 2015 at 13:41, Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl> wrote: > On Fri, Apr 10, 2015 at 03:17:37PM +0300, Tomasz Bursztyka wrote: >> Hi, >> >> As it has been discussed in the systemd hackfest during the Linux Conference >> Europe, one daemon could centralize the management of all network proxy >> configurations. Idea is something user can do per-application (like in >> firefox for instance) or broader (per-DM like in Gnome), user could do it >> once and for all through such daemon and applications would then request it >> to know whether or not a proxy has to be used and which one. >> >> As a notice, this is nothing new. Such standalone daemon has been already >> done by the past, pacrunner. systemd-proxy-discoveryd will more or less >> implement the same ideas with improvements. It will get rid of big JS >> engines like spidermonkey or v8 which are overkill for the tiny PAC files >> to be executed on, for instance. From pacrunner experience, APIs will be >> also improved. > Hi, > > the idea of having centralized proxy config is certainly nice. But the > PAC files make me shiver. So the first question: is it really necessary > to support PAC files? Are they widely used in corporate setting or something? > Is there no saner standard? >
Yes. Yes. No. I only wish for system-wide WPAD support and PAC auto-parsing. The standard started by netscape or some such, hence interpreted javascript, and nobody came up with something more declarative / deterministic that catched on. > If the PAC files must be interpreted, I think this is the hardest > part. FindProxyForURL is started for every request, potentially > hundreds of times per second and more. This means that starting a > process per invocation is out of the question, and even starting a > thread per invocation seems to be too much. But each call fall into an > infinite loop and hang. So the run time of FindProxyForURL should be > bounded. FindProxyForURL can also resolve names over the network, > which would best be done asynchronously. > Well pac file is generally cached, and is static it its contents (possibly many complex clauses if this / if that) but it's ideal to keep it around for subsequent queries. > Things in systemd are usually implemented through poll loops, which > makes it easy to support thousands of concurrent "jobs". I'd think > that this would be the best option here too, with a number of "workers" > executing FindProxyForURL()s and stopping when name resolution is > requested and continuing when the name is resolved. > > Zbyszek > _______________________________________________ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Regards, Dimitri. https://clearlinux.org Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
