On Thu, 15 Nov 2012 22:27:23 +0900 Carsten Haitzler (The Rasterman) <[email protected]> wrote:
> On Thu, 15 Nov 2012 22:45:31 +1000 David Seikel <[email protected]> > said: > > > On Thu, 15 Nov 2012 21:26:25 +0900 Carsten Haitzler (The Rasterman) > > <[email protected]> wrote: > > > > > On Thu, 15 Nov 2012 16:33:35 +1030 Simon <[email protected]> said: > > > > > > > On 11/15/2012 04:40 PM, Carsten Haitzler (The Rasterman) wrote: > > > > > On Thu, 15 Nov 2012 15:05:51 +1030 Simon Lees > > > > > <[email protected]> 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. You do keep bragging that clock is written in edje / embroyo. Sure there has to be some C code to actually load the edje into a modules graphics object, but brag about it you have. B-) > > 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. Actually, LuaJIT can do something like that. I've not played with that part of LuaJIT yet, but I'm looking at maybe using it to help with the edje Lua <-> EFL function interface boilerplate. That stuff is boring to write, and LuaJIT I think can automate most of that away. I've mentioned before that I'm working on a project that uses EFL, and LuaJIT. Apart from getting it to do what the project is all about (script engine for a virtual world), it's also a test bed for using LuaJIT in EFL. Have I mentioned it's fast? It's faaaaaaaaaaast! It's generally acknowledged that LuaJIT is the fastest script runner on the planet. I'm liking it so far. Remember we talked about sending Lua tables / calls across the 'net and other fun things? Guess what one of my use cases was? I've got an experimental variation on that idea already for my virtual world script engine, though so far only in a test harness. > 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... :) That's precisely what emu was doing. I was testing it with a bash script, doing it via the scripts stdin/stdout, defining a menu tree, getting events back from E17. It hooked into the border menu as well as two of the desktop menus, and had it's own module menu that could be defined. The other stuff is on the TODO, which is in SVN. Though obviously things have been invented since then that are not on the TODO, but likely would have been if I had known about them at the time. B-) I'll put "resurrect the poor dead bird" on my TODO. My TODO runneth over. sigh -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
