On Mon, Sep 19, 2016 at 8:44 PM, Carsten Haitzler <ras...@rasterman.com> wrote: > 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.
I've checked what you did for curl, since I use that and need more symbols. my question and concern are just: - not being able to compile without libproxy. If we always detect, should we remove --enable-libproxy from configure.ac? - I ask the above because libproxy is a monster, it will pull in a JS loader, glib, C++... all of that, per process. If using pacrunner (from connman guys) you can just link with libdbus, less bad. > 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... whatever you want, like https://github.com/libproxy/libproxy/tree/master/libproxy/modules they have config_envvars that check http_proxy, no_proxy... but they also have one for gnome that uses gsettings. >> 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! indeed. At least pacrunner isolates this in their daemon, not every process. And the file is shared... not to say they picked a light JS engine (duktape) as the wpad.dat is super-simple. >> 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). less bad, but still one per process doing networking. >> 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. I can do this very easily, 3 functions, no public struct, just returns a char **. > 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. I'd say the sanest route is: - dlopen trick on libproxy (3 functions) - hint packagers on optional dependency on libproxy - don't bother with libproxy.so (traditional) impact, hint users to go pacrunner. Note my code already uses libproxy 'get proxies for url' in a thread, as they recommend in their project. - use pacrunner where performance matters. - push distros to package pacrunner (glib + dbus + curl, very simple) AFAIU (still trying to get more details on the working), pacrunner will interact with connman's proxy configuration... I need to stop and read/ask which one is the controller. But that's the ideal situation, we already do connman, set property there and it spreads to the whole system. -- 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
