On Thu, 11 Jan 2018 19:07:54 -0500 Cedric Bail <ced...@ddlm.me> said:
> > -------- Original Message -------- > > Subject: Re: [E-devel] Creating Enlightenment Gadgets > > Local Time: January 11, 2018 12:40 AM > > UTC Time: January 11, 2018 8:40 AM > > From: ras...@rasterman.com > > To: Enlightenment developer list <enlightenment-de...@lists.sourceforge.net> > > Enlightenment users discussion & support > > <enlightenment-users@lists.sourceforge.net> > > > > On Wed, 10 Jan 2018 20:38:27 +0000 Stephen Houston smhousto...@gmail.com > > said: > > > > i'm going to put my take on this: i think this is bad. it flies in the face > > of everything e was built to do. to be efficient. having a process per > > gadget is horribly inefficient. this is precisely what helps bloat out > > gnome and kde memory footprints and what has kept e lean. > > Their are ways to work on reducing this overhead and some are not so far away. a lot can't be removed. gl overhead for example (heap/allocation) if you want to use acceleration for everything where you can. the others require the horrible forking stuff and that is just plain nasty to deal with especially with fd's, threads etc. ... quicklaunch has been a royal pain and is just not worth it. it has far too many side effects. > > while avoiding e crashing due to a bad gadget is a good thing, the > > following is just a bad way to do it. > > > > 2 other alternatives: > > > > - have a SINGLE "gadget process" to hold all gadgets and load modules into > > this process, so we don't have 20 processes, but instead have just e + > > gadget process. > > - remote ui. gadgets could be written in any language that can do stdio. > > they echo/printf commands to e to create objects and change their state, > > and e "echos" back on stdin events and things the gadget should know. your > > gadget could be a stripped down super-lean basic libc executable. python. > > shell script. anything that can do stdio. while this still has 1 process > > per gadget - it's for the back-end only and this should make then far > > leaner than with a full ui. > > > > i actually wanted to spend time on #2 but am busy with efl atrm. #2 would be > > great because it'd massively lower the work needed to quickly make a gadget > > of your own. write it in python or shell quickly and dirtily and life would > > be easy. > > Solution one has many drawback. First one is that you are sharing information > between module when you might not want to. Second obvious drawback I see is and in what cases does this actually matter? if you want to sandbox every module/gadget then i think that is going far too far. my take is that a module/gadget is a trusted tool that is integrated with your desktop. thus the above doesn't count. and if you really do want to isolate then using something like elua and a private lua state per gadget would work best as then it doesn't mean we have to duplicate the entire process N times, only a fairly minimal lua state (in comparison to the rest behind it). > that you can't do easily use your favorite language. This also means that one > single bad behaving gadget will take everything down. You get the idea. it takes down only the gadgets, not everything. and then kill and restart the gadget process brings them all back. yes - the impact is wider then than just that single gadget but it's far more efficient, and the rest of your desktop still works just fine. > Proposition two is very limited and quirky to use. Not many people are > looking forward into using stdio as a medium of communication. You would have > to start writing wrapper for various language and this would be a second API > to learn. Also it feels like it would be limiting in term of API compared to > being able to push whatever pixels you want. How would you for example be > able to use evas object VG to draw curve ? Does that means we would need to > wrap all of EFL API to work via stdout ? /o\ no - it'd be limited. but over time more and more display mechanisms would be exposed. so for example eventually a graph object where you just provide N points via stdout and the native code either in efl as a widget or in e as a shared display object take care of the rest. it'd make it easier to theme e as themers only have to theme the standard objects like a graph display "widget" and the anything needing that looks consistent and "nice". most gadgets all fall into a pattern. they have an edje object, set some text fields, emit signals, send messages, popup some popups with some content (some text and images, or a list of things to select etc.) that it'd be pretty easy to cover most use cases very quickly. the fact you can hack together a gadget in 100 lines of shell script with some echos would make life pretty nice. i don't see why you need an api wrapped. if it's simple enough to printf/print/echo then it should not be a problem. > I feel that the current design open a lot of new potential to E that wasn't > there before. It is in addition to the possibility to still do module like > before, so doesn't remove anything. Now you can use your language favorite, > python gadget anyone ? You can also start doing more complex program like a > crypto currency wallet without the problem of sharing information with the a crypto wallet should actually split into a back vs front end as you want the back end written as simply as possible so it has a little attack-surface as you can manage. the more libs/toolkits it uses the larger its attack surface. > rest of E. You can also start putting together a repository for gadget online > and allow them to run in a sandbox like firejail with limited risk for the > system. There is a lot of positive possibility that this new gadget > infrastructure is enabling. will be incredibly rare to want to do this (sandbox your gadgets). as i mentioned above. for cases where security is an issue they should probably split into a very simple back-end that is very locked down and a front-end to talk to it and authenticate etc. the back-end maybe at most would reauest an auth itself (e.g. may execute enlightenment_askpass or have a ui of its own though this makes it more complex, or have a passwd asking tool of its own it directly runs etc. etc.). > Cedric > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > enlightenment-devel mailing list > enlightenment-de...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
