On Tue, 06 May 2008 13:41:12 -0400 Jose Gonzalez <[EMAIL PROTECTED]> babbled:
> Gustavo wrote: > > >> >>> > >> >> What's the relevant notion of: "self-hosting" edje application? personally i think it's not useful beyond development/debugging and when designing themes. edje was NEVER intended to write programs with and has a very limited set of api calls it can call from embryo as a result. a self-hosting edje program imho just is not a good idea. it was not designed for it. it's programming model is inconvenient at best for writing programs, and edje will always heavily limit any IO and access for security reasons. > >> Then one needs to extend edje/embryo scripting far more than > >> it's currently capable of.. and for it to be sufficiently capable > >> for general kinds of 'apps' it may need to have access to system > >> calls and other things. One'd also need to have well-known entry > >> points into the .edj file - either a special main group or a special > >> script function to execute on load or some such, and have all being > >> executed in some kind of 'runtime'. i have plans to do this with edje. it'd actually be very simple. the plans go like this: 1. allow edje objects to be ONLY defined by embryo script. right now you can specify a message handling callback for an object and then script sections when events (programs) get triggered. there is always one on load so it's easy to run code when the object is loaded for setup etc. etc. but i want to go further and add a resize() callback and a part_text_set() callback and then the code logic here handles all of that. 2. combined with #1 above add more hooks for the script to be able to CREATE and DESTROY and MANIPULATE evas objects directly. edje would track these make sure they are cleaned up on object destruction and maybe enforce limits (like no more than 1000 objects or some user settable limits). 3. add the ability to load other edje objects from the same file, so you can mix and match the older layout and declarative way of doing objects and the script/code way. 4. add a few more calls like adding/deleting pollers this should allow you to pretty much do anything that flash does with actionscript, BUT only locally within a limited sandbox. i do NOT intend to add network access or any filesystem access or anything else - this is dangerous. you download and use a theme (blindly) and suddenly it's reading your emails and sending them of to someone else. themes are NOT programs. they are not meant to be. you should not have to even think of security with them. at worst they should just be annoying and useless. > >> Note that things like Flash/mxml (then to swf) or Silverlight/ > >> xaml (may also have some binary representation), unlike edje/edc, > >> have extensive 'script' language support and allow for separating > >> the code logic from the 'gui' part in separate files if desired > >> (though I suppose one could do this with edje/edc/embryo). edje is not far of there. see above. it needs just a few calls and exporting some evas and edje controls and bingo. you can do just the same. embryo is a full VM and language. most of the nuts and bolts are there - just the api hooks need adding really :) BUT edje is intended to be a helper and separator for programs to use to create interfaces. > > The whole point of using Embryo instead of other VM is exactly that > > you don't have any access to user's machine. I agree with that, I'd > > avoid adding these calls, for such thing we can use Python or Ruby or > > other scripting languages with full-system support, they have > > different scope. exactly. edje has a full mssaging interface where a calling app (be it c, c++, ruby, python or whatever) can message abstract information to the edje and also have edje message he app back. if they understand each others messages then the app can pass information to edje at a high level and vice-versa. so the app can selectively expose system information to the edje object as it sees fit - but that is the TASK of the app. it is KNOWN that that is what it does. allowing edje objects the power to just go fetch it themselves is opening a doorway so wide that it has massive security, privacy etc. implications and now every theme needs to be checked for possible security and privacy violations. when you set a wallpaper on your desktop you don't EXPECT to need to get a security audit. edje is just a very powerful "jpeg". when you compile and run an app you expect that it has been audited (thus its in the package repository for your system) or its an accepted risk you take in installing it. it's a matter of managing expectations. > Yeah, and it sounds like a fine 'security minded' approach.. > but in practice it's not going to make much of a difference since > edje is used along with all sorts of code that's highly insecure. see above. it is important. it's a mistake microsoft have made all over the place for years and have spent years cleaning up. vb script in word documents able to take your files and modify them or destroy them or send them to others etc. > What difference does it make that embryo itself can't access > system calls when you have e17, e17-modules, all-sorts-of-apps/libs > that use edje being written in C that can access anything and > everything? Might as well have your 'scripting' language be able > to do the same and restrict its use in edje itself to only 'safe' > calls. it does matter - managing expectations. i don't expect a skin/theme to go do anything bad. at worst just be annoying and look nasty or be unusable. an APPLICATION i install i DO expect it to DO things. to interact with my system somehow. if it does something wrong - then at least its within the realm of expectation. > The only way things will ever come close to a realistic notion > of 'secure' will be when the host OS itself can be split into > virtual, insulated versions of itself that are limited and private > to a given user - far more than the current unix like permissions > system gives. there are levels of security. for edje i chose one that allows the edje object some freedom within a limited sandbox. any c apps of course are "game over" as frankly - its a program like everything else. but that is a known factor already and has been the case ever since. when introducing something NEW like edje i chose to make sure i don't open a massive doorway of security problems. > In any case, even if one wants to keep embryo to a limited VM > (which is fine), there are still many ways in which its use with edje > could be extended.. possibly even allowing for edje/edc and edje_cc > to support other scripting languages - javascript could be good one. definitely not. not only would this blow out requirements for edje now that you need to drag along multiple scripting languages, he memory footprint of these are HUGE compared to embryo - MASSIVE. remember every object would need its own script instance. i hasve measued the speed of embryo vs java, python, ruby, perl and c. embryo is by far the fastest except for c. it is the smallest. yes - it's simple - but it is intended to augment the logic of the ui, not write whole programs with, and for this you don't need advanced programming constructs. > Alternatively, there's no need that edje should be everything to > everyone, and it might be better to have other things address further > needs, eg. evolve/edc for more involved widgets, maybe other animation > mechanisms, etc. it should help abstract the ui from the code. it should not become the code. as above. i have had plans for a long time and will get to them eventually - it's all easy to do. i just have no NEED for it right now, and have other things to do, so i haven't done it. > > I think that Andreas idea is close to mine: allow users to have nice, > > beautiful toys, that are really easy to make with pure-Edje/Embryo > > today, as it was demonstrated by Dave's calculator. Another examples > > would be calendar viewers, little games and more... Please don't > > consider these "apps" like we're used to, I don't see any need for > > themes, since you just need to get another app that looks like you > > want. > > You may not see any need for themes now, but you/others may well > see differently in time.. especially if more complex examples of such > things became common. Re-usability and modularity eventually come > forefront - whether it's at design/development time or at runtime.. > and 'themes' are just one example of that. > Replacing one 'toy' with another just to have it look somewhat > differently may be fine for small toys.. but not everyone is going > to limit themselves to wanting or writing only small toys.. and even > then, theming will always be something people will want. Look at the > entire history of guis, desktop or web related, and read the writing > on the wall. :) > > > That said, I see some room for improvement: > > - some persistance, either sqlite or eet support from embryo, > > allowing save minor state. This should be sandboxed as well; > > - some call, could be a change of size hint -- see property and > > callback, that would make the app host (ie: loader) to resize), maybe > > calls to make it fullscreen; > > - evas.inc (evas bindings for embryo); > > - gettext.inc (gettext bindings for embryo), maybe make gettext > > support transparent for strings... this would be a great addition to > > Edje: add a flag to mark TEXT/TEXTBLOCK as translatable and pack .po > > inside .edj > > > > having http+xml (maybe xmlrpc for easy of use) would help, but would > > make it more unsafe, the loader would have to specifically control > > whenever the .edj would have such permissions, thus I don't think it's > > something for now, but the above ideas are easy. > > > > > Not before you finish that gl stuff you mentioned you wanted to > play around with. :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
