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

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 :-)

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

enlightenment-devel mailing list

Reply via email to