On Mon, 19 Sep 2016 11:31:58 -0300 Gustavo Sverzut Barbieri <barbi...@gmail.com> said:
> 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). ummm i just am looking now (i have a lot of catching up to do). can you undo the changes to configure.ac and make this a dlopen/dlsym approach? well use eina_module. look a the old curl eina_module approach. look at what i did in ecore_audio too. in fact i need to look over all the efl net code, but you want to use emile for ssl stuff and eina_module for curl too there too (i haven't looked yet). there are very good reasons to do all of this. emile too needs to switch to using this approach internally as well. > 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. what kind of config? you mean like a dbus interface exposed from e to provide proxy info? i haven't looked... > Just be aware that libproxy is nasty and will load many crap in your > application binary, including mozjs to interpret JS mentioned above. ugh. i know. pac files. js in there. ugh. it's times like this that all the "web tech crowd" makes me want to cry. it's like they never cared about performance... ever. just stuff some js anywhere because we have a browser using it already and hey whats an extra few mb to something already needing 1gb to run... :( oh wait1 we already have js spinning so it's no cost to us! argh! > 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. much better, OR we even spin off a process - let it execute as a child, read back results in parent (and cache them until proxy data changes). > 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. we do indeed live inside one at work. and there is the PAC file from hell... > 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 :-) please please... don't race! you bring up very important things above. also dlopen the sucker. don't make it a configure option + link option. runtime link as needed. duplicate whatever elements of the libproxy headers needed to talk to it. we need to do much more of this for "rarely used dependencies". unless it's needed by like 80%+ of apps, then it should be dlopen'd instead of linked. linking is EXPENSIVE. also the issue running the PAC files... it makes sense to ecore_exe() a slave and have it figure it out once and store the result (ok ok PAC files technically have to be re-executed per connect because they can switch per target... urgh). we COULd do it like efreet with a daemon approach for now. we can support pacrunner as a daemon later too and avoid running our own. in fact this is likely the best approach - do it the efreetd way. no no. do not use dbus. yes i know it does activation for us. no. this is far more trouble, but i won't get into that here. just connect to a local user ipc service of our own, if not there, spawn the daemon and try connecting again a bit later. repeat until connect succeeded. do it in background async. > -- > 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
