On Tue, Sep 20, 2016 at 1:54 AM, Carsten Haitzler <ras...@rasterman.com> wrote:
> On Tue, 20 Sep 2016 01:08:48 -0300 Gustavo Sverzut Barbieri
> <barbi...@gmail.com> said:
>
>> 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?
>
> yes. it moves to runtime not compile-time. several reasons:
>
> 1. makes compiling simpler. people dont have to find dependencies and those
> -dev/devel pkgs too. if they add libproxy later after building efl magically
> the feature works without a rebuild.
> 2. speed up startup time with less linking going on for apps especially for
> features they may never use
> 3. saves memory - symbol tables and dirtying private pages to do the symbol
> fixups is expensive. i nuked like 320k or so before 1.18 release of actual
> real memory usage that was dirty pages from rarely used libraries.features.
> it's expensive and so only load in if/when needed to save this cost. this cost
> is private pages PER PROCESS using efl so it multiples and is not a one-off
> cost.
> 4. the idea of isolating such costs into a proxy daemon/process probably is a
> good thing and that saves adding the above cost for any process then needing
> to
> do proxy pac file parsing etc. and isolates the cost into a single daemon.
I was asking if we should offer a way to not even try runtime detection.
>> - 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.
>
> in GENERAL go for a dlopen(eina_module) style approach, BUT if a daemon makes
> sense, then do that.
It's not something that excludes the other. Actually the opposite if
we do the proper way.
- efl does libproxy dlopen, so doesn't link to that library (simple
API but heavy in dependency)
- efl could recommend pacrunner's libproxy until we do our own, a big
improvement - zero work
- efl could provide its own libproxy.so, like
/usr/lib/enlightenment/libproxy.so which would talk to our own server
(which can be built to use system's libproxy, which in turn can be the
official one or pacrunner's drop-in replacement). Our dlopen() can
prefer that version.
- we can employ LD_PRELOAD tricks in Enlightenment to force loading
our libproxy.so instead of the system. Our daemon must be started
without it, of course :-)
>it makes more sense for us to do our own daemon for efl
> like efreet. dbus is not a good solution for this.
agreed, the API is simple so a pure unix socket can do, protocol is:
send: <int:url_length><char[]:url>
recv:
<int:count><int:proxy1_len><char[]:proxy1><int:proxy2_len><char[]:proxy2>....
as libproxy IS blocking and they explicitly recommend to be called
from a thread, our code will be simple send/recv calls, no other
libraries to pollute our users.
> supporting pacrunner later
> of course is doable, but i would not do this out of the box because pacrunner
> is not everywhere, dbus session buses do not exist when you do things like use
> the console (terminology using fbcon is a major problem when it comes to
> ethumb
> and was for efreet because no session bus is active thus everything bound to a
> session bus is broken). i will eventually rewrite ethumb features likely in
> elm
> and drop ethumb because of such issues. also ethumb design is broken for SMACK
> systems so we really do need a "fork off a slave process that is custom for
> your app only" method of working.
you know my opinion on this: this is a nasty approach. The dbus is
simple to achieve if you start that, as you do in E if there was no
session. Or use systemd, it should be doing that from pam_systemd.
SMACK is a different issue and the design of Ethumb came from a time
where we expected all processes to share thumbnails, like efm, your
elm file selector, etc. Private thumbnails as you mentioned started to
gain traction later... application isolation as well, it began with
iOS/Android, linux desktop still is not there.
> for proxies i see the value of a single efl.net.proxy daemon service to serve
> as a proxy handler - send relevant info to this daemon, let it decide and then
> answer back with what connection to make. so basically take the libproxy stuff
> you just committed, move it to a daemon (like efreet does now), and connect to
> it (execute then connect if connect fails). if you don't, then i'll eventually
> need to do this.
see my plan above, sounds progressive and we don't need to redo
anything. It will work right now, if pacrunner is there it will work
and if we ever create a daemon, we can provide a libproxy.so to be
LD_PRELOAD'ed on apps (pure libC shim).
> keep this in mind as a design point. for data that is "global" (efreet style
> stuff, proxy info etc.) then a single daemon doing the work will be the best
> solution. maybe in future we might/can merge these daemons into a single "efl
> daemon".
indeed makes sense.
>> > 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.
>
> err so you mean write code into libproxy to get proxy settings from e? a quick
> look at the above implies that... is there a way of hooking into this e.g.
> from
> the above "efl proxy daemon"? actually i'm sure there is...
from what I understand, you create a module ("mm_info_" symbol), see
https://github.com/libproxy/libproxy/blob/master/libproxy/modules/config_gnome.cpp
then you put it in /usr/lib/libproxy/${VERSION}/modules/. That module
can provide a function to say if the module should be used, like based
on envvars.
> either way a single daemon would solve a lot of the above issues of libproxy
> pulling in half the universe into every app needing to do network stuff.
agreed. BUT looking at ArchLinux packaging, well-known software does
link to that... glib-networking qt5-base vlc. Definitely we can and
should improve, but it's not a blocker.
>> - push distros to package pacrunner (glib + dbus + curl, very simple)
>
> we pushed connman years ago. not again. distros just don't want to. we need to
> DIY and provide our own "pacrunner". that's easy enough for us as we do it
> with
> efreetd already. we have lots of infra to do this easily. if we just have an
> eflnet "proxy handler" and efl.net spawns and talks to it we have a solution
> that doesn't require pacrunner to be packaged and so on (going by history of
> connman i just dont want to go here again), and it's TRIVIAL for us to
> support.
> you have there all the relevant code already. just needs to be put into its
> own
> binary, with an ipc/whatever conn for the user and some code to connect and/or
> launch it.
doing this way will not help, just creates another technology just our
apps will use... and frankly that would benefit what? just terminology
to get previews, E to check updates?
most of the other software doing network uses that libproxy, like I
said, qt/glib, vlc... thus all of those would be missed. We need a
solution that works for all of them, so the libproxy drop-in repl.
also, doing the pacrunner ourselves brings what to the table? Almost
nothing other than work. libproxy already talks to neworkmanager.
pacrunner talks to connman. We'd have to also monitor these. We'd need
to pick a JS, expose functions, do testing... It's not as simple as it
looks like, having a main loop and few C helpers won't help much :-/
>> 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.
>
> the problem is 99% of users dont want or use connman. after years i've seen
> that and i don't see that binding ourselves even deeper is a good idea.
> connman
> works fine. i use it personally. but it's just not palatable for distros or
> users. providing our own little proxy daemon process like efreetd would be a
> self-sustained solution that is GUARANTEED to be installed and work in every
> environment.
as per above, it's not solving any problems, just adding more.
--
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
