On Mon, Sep 19, 2016 at 11:31 AM, Gustavo Sverzut Barbieri
<barbi...@gmail.com> wrote:
> Hi all,
> Today I did commit support for libproxy in ecore_con's new API,
> Efl.Net.Dialer.Tcp, Efl.Net.Dialer.Http and Efl.Net.Dialer.Websocket
> (implicit from HTTP).
> Libproxy (https://libproxy.github.io) tries to dynamically find a
> proxy for a given URL, unlike plain $http_proxy, $no_proxy... which
> needs a mess to get right in complex environments such as big
> corporations. It will also use PAC - ProxyAutoConfiguration, those
> JavaScript like files named wpad.dat, as well as the wpad host on the
> local network, where it tries to find the JS file.
> More than that, libproxy uses the configuration from Desktop
> Environments. There are none for E (some volunteer?), but we can use
> the one from Gnome3/Gnome or KDE. It will also handle envvars and some
> /etc/sysconf configuration.
> Just be aware that libproxy is nasty and will load many crap in your
> application binary, including mozjs to interpret JS mentioned above.
> A better solution is to use libproxy replacement from pacrunner
> (http://git.kernel.org/cgit/network/connman/pacrunner.git/), that one
> will only pull in libdbus and the JS is done at the daemon, which also
> keeps shared cache not replicating it in all processes.
> Be traditional libproxy or pacrunner's alternative, the current code
> should be more dynamic, however needs more testing. If you work inside
> a proxy, give it a try and report problems, you can use the
> src/examples/ecore/efl_io_copier or efl_net_dialer_http_example to
> test.
> It's important to get more testing as in near future I'm converting
> parts of E/EFL that used ecore_con to use this and I don't want to
> break things :-)

Ah, and I forgot to mention that pacrunner is developed by the same
team as connman, so uses its configuration... all nicely integrated

Gustavo Sverzut Barbieri
Mobile: +55 (16) 99354-9890

enlightenment-devel mailing list

Reply via email to