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 :-) -- Gustavo Sverzut Barbieri -------------------------------------- Mobile: +55 (16) 99354-9890 ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
