On Thu, 15 Nov 2012 22:45:31 +1000 David Seikel <onef...@gmail.com> said:
> On Thu, 15 Nov 2012 21:26:25 +0900 Carsten Haitzler (The Rasterman) > <ras...@rasterman.com> wrote: > > > On Thu, 15 Nov 2012 16:33:35 +1030 Simon <si...@simotek.net> said: > > > > > On 11/15/2012 04:40 PM, Carsten Haitzler (The Rasterman) wrote: > > > > On Thu, 15 Nov 2012 15:05:51 +1030 Simon Lees <si...@simotek.net> > > > > said: > > > > > Out of interest will e18 contain the ability to sandbox 3rd party > > > modules so they can't take down the whole of enlightenment? one of > > > the > > > > by definition, they can't be sandboxed. they are runtime patches to > > code basically. they are just "more code stuffed into e" thus why > > they can cause bugs. there is no way to sanboxe them and NOt provide > > access to all of memory of e, function calls etc. - then they are no > > longer modules. > > > > what you are wanting is separate PROCESSES that talk to e (eg via > > ipc) and ask it to do thnigs. these are safer, and can mess up on > > their own all they like and not kill e.. the other way is a vm setup > > - eg some scripting lang that is interpreted and thus sandboxed. > > modules were designed to make it possible to WRITe such a sandbox > > module - one that runs a lua, js, embryo, pyhton or whatever runtime > > and then glues in access to e and efl via bindings. as such such a > > thing doesnt currently exist, but it is possible to do. at this point > > there are no concrete plans to do this, but maybe using elev8 and > > making a libelev8 is a good way to go. > > Um, you have used embryo yourself to make a module, and you insisted I ummm.. no i haven't. there is no way to write "embryo" and load it as a module. there is no MODULE that can load "embryo bytecode" and run it. if you are alluding to edje - then that is a totally different kettle of fish. a module gets access to augment, modify and change vast amounts of e. embryo (or lua) in an edje object is highly limited to live just within the object bounds itself. the edje object is not a module.. it's a data file. > sandbox edje Lua plenty, it could be used for a module as well. I plan it could be. that's what i was saying. > on writing Lua E17 modules some day when I get around to it. Sure, > they can't do everything a C module could do, but that's the point of > sand boxing. > > On the other hand, I did start writing the emu module, which was a > generic module that interfaced to E17 via IPC, allowing people to write > modules in any language they like, with the full protection you > mention above. It bit rotted long ago though while I got busy with > other stuff. Which is your first method. I'm sure a bit of love could > resurrect it without too much drama. yeah. this would be really nice to resurrect. though the problem really is making it easy to expose "functionality". that's hard. we'd need some kind of script or processor that can take a c func signature and present it as a packaged ipc call. same for emitting ipc events. for r18 i want to make a module that allows external gadgets. more limited, but it can use the ecore_evas_plug/socket setup and thus within a small world it can expose its canvas via shm to e. with some extensions like being able to request popups (mixer, baklight) and define a menu tree for e to manage and send back events on what gets selected... this could cover a LOT of modules with a much simpler set of ipc. hell... it could be done via stdin/out.. then you literally could write them in bash... if u wanted... :) > So both methods already exist. Sorta. > > -- > A big old stinking pile of genius that no one wants > coz there are too many silver coated monkeys in the world. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
