Re: [systemd-devel] [RFC 0/6] A network proxy management daemon, systemd-proxy-discoveryd

2015-08-14 Thread Tomasz Bursztyka
Hi Lucas, Maybe, maybe not. It was not said publicly in that thread, but some systemd guys are nacking this due to the JS engine it would provide. Tom contacted me in private to tell me this is put on hold (though himself, he really want that service to get in, as Lennart and David). I guess

Re: [systemd-devel] [RFC 0/6] A network proxy management daemon, systemd-proxy-discoveryd

2015-08-14 Thread Tomasz Bursztyka
Too used to reply to all. well... Hi Lucas, Maybe, maybe not. It was not said publicly in that thread, but some systemd guys are nacking this due to the JS engine it would provide. Tom contacted me in private to tell me this is put on hold (though himself, he really want that service to

Re: [systemd-devel] [RFC 0/6] A network proxy management daemon, systemd-proxy-discoveryd

2015-08-13 Thread Lucas De Marchi
Hi Tomasz, On Fri, Apr 10, 2015 at 9:17 AM, Tomasz Bursztyka tomasz.burszt...@linux.intel.com 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

Re: [systemd-devel] [RFC 0/6] A network proxy management daemon, systemd-proxy-discoveryd

2015-07-16 Thread David Woodhouse
On Fri Apr 10 05:17:37 PDT 2015, Tomasz Bursztyka wrote: 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

Re: [systemd-devel] [RFC 0/6] A network proxy management daemon, systemd-proxy-discoveryd

2015-07-16 Thread Tomasz Bursztyka
Hi David, On Fri Apr 10 05:17:37 PDT 2015, Tomasz Bursztyka wrote: 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

Re: [systemd-devel] [RFC 0/6] A network proxy management daemon, systemd-proxy-discoveryd

2015-04-13 Thread Dimitri John Ledkov
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

Re: [systemd-devel] [RFC 0/6] A network proxy management daemon, systemd-proxy-discoveryd

2015-04-13 Thread Tomasz Bursztyka
Hi, Have you looked into MuJS instead of duktape? http://mujs.com/ It has a C api similar to Lua, with all state encapsulated in an opaque structure, that you interface with via a virtual stack. It could be easily tested. I did so the PAC related code is contained in a specific place,

Re: [systemd-devel] [RFC 0/6] A network proxy management daemon, systemd-proxy-discoveryd

2015-04-13 Thread Marcel Holtmann
Hi Tomasz, Have you looked into MuJS instead of duktape? http://mujs.com/ It has a C api similar to Lua, with all state encapsulated in an opaque structure, that you interface with via a virtual stack. It could be easily tested. I did so the PAC related code is contained in a specific

Re: [systemd-devel] [RFC 0/6] A network proxy management daemon, systemd-proxy-discoveryd

2015-04-13 Thread Dan Williams
On Sun, 2015-04-12 at 20:31 +0200, Lennart Poettering wrote: On Fri, 10.04.15 14:05, Dan Williams (d...@redhat.com) wrote: So idea would basically be that we provide in all three daemons calls like: SetAdditionalNTP(ias) SetAdditionalDNS(ia(uay))

Re: [systemd-devel] [RFC 0/6] A network proxy management daemon, systemd-proxy-discoveryd

2015-04-12 Thread Cameron Norman
On Fri, Apr 10, 2015 at 5:17 AM, Tomasz Bursztyka tomasz.burszt...@linux.intel.com wrote: Hi, [snip] 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.

Re: [systemd-devel] [RFC 0/6] A network proxy management daemon, systemd-proxy-discoveryd

2015-04-12 Thread Daurnimator
On 13 April 2015 at 07:12, Cameron Norman camerontnor...@gmail.com wrote: On Fri, Apr 10, 2015 at 5:17 AM, Tomasz Bursztyka tomasz.burszt...@linux.intel.com wrote: Hi, [snip] As a notice, this is nothing new. Such standalone daemon has been already done by the past, pacrunner.

Re: [systemd-devel] [RFC 0/6] A network proxy management daemon, systemd-proxy-discoveryd

2015-04-12 Thread Andrei Borzenkov
В Sat, 11 Apr 2015 19:41:15 + Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl пишет: 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

Re: [systemd-devel] [RFC 0/6] A network proxy management daemon, systemd-proxy-discoveryd

2015-04-12 Thread Lennart Poettering
On Sun, 12.04.15 12:51, Marcel Holtmann (mar...@holtmann.org) wrote: Hi Lennart, 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

Re: [systemd-devel] [RFC 0/6] A network proxy management daemon, systemd-proxy-discoveryd

2015-04-12 Thread Lennart Poettering
On Sat, 11.04.15 19: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

Re: [systemd-devel] [RFC 0/6] A network proxy management daemon, systemd-proxy-discoveryd

2015-04-12 Thread Marcel Holtmann
Hi Zbyszek, 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

Re: [systemd-devel] [RFC 0/6] A network proxy management daemon, systemd-proxy-discoveryd

2015-04-12 Thread Marcel Holtmann
Hi Lennart, 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),

Re: [systemd-devel] [RFC 0/6] A network proxy management daemon, systemd-proxy-discoveryd

2015-04-12 Thread Lennart Poettering
On Fri, 10.04.15 14:05, Dan Williams (d...@redhat.com) wrote: So idea would basically be that we provide in all three daemons calls like: SetAdditionalNTP(ias) SetAdditionalDNS(ia(uay)) I would strongly suggest using strings in the API for IP

Re: [systemd-devel] [RFC 0/6] A network proxy management daemon, systemd-proxy-discoveryd

2015-04-12 Thread Marcel Holtmann
Hi Lennart, 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

Re: [systemd-devel] [RFC 0/6] A network proxy management daemon, systemd-proxy-discoveryd

2015-04-12 Thread Lennart Poettering
On Sun, 12.04.15 12:49, Marcel Holtmann (mar...@holtmann.org) wrote: PACrunner is an existing implementation of this concept. It uses threads and seems to work just fine. We bridged libproxy API compatible library that talks to the PACrunner over D-Bus. How does the abort-after-max-runtime

Re: [systemd-devel] [RFC 0/6] A network proxy management daemon, systemd-proxy-discoveryd

2015-04-11 Thread Zbigniew Jędrzejewski-Szmek
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