On Tue, Jun 7, 2011 at 10:23 AM, Mike McCormack <mj.mccorm...@samsung.com> wrote: > On 06/07/2011 04:29 PM, Nicolas Aguirre wrote: >>> Added: >>> trunk/PROTO/elev8/data/javascript/ >>> trunk/PROTO/elev8/data/javascript/button.js > >> Im' just curious, but what's this javascript stuff ? What's the difference >> with elixir ? > > Hi Nicholas, > > Elixir wraps EFL function by function, however elev8 will abstract away the > detail > of writing EFL applications. > > For example, main loops, windows and backgrounds will be created > automatically. > > It's still in the prototyping phase at the moment, so if anybody has any > flames > or suggestions, please fire away :-)
That's an interesting concept. I would like to take that opportunity to give feedback from my experience with elixir and its community. First a little background, elixir was created by Freebox S.A.S. to be a way to create apps on the Freebox v5 set top box (a poor little mips at 250Mhz with a limited graphic blitter and 64MB of RAM). As this set top box is only delivered to French ISP customer Free, the comunity is exclusivly french. A web site and a svn with example was open for it at http://code.google.com/p/freebox-elixir/ . Free did have around 2millions active set top box and around 200 developpers were activ. It resulted in around 150 apps behing since August 2010 (The SDK was first deployed and installed on all set top box in november 2009, but the AppStore like interface only came later in August 2010). We also did a weekend of introduction/teaching to 70 developpers in Paris with the help of the french Enlightenment community early in 2010. Biggest hit is http://www.bouncebox.fr/ a network game with a permanent 100 users playing with it. Other successfull apps get downloaded around 2000 times. The number of active developpers only increased once the store to easily deploy apps was available. All that numbers are public. Now what is Elixir, and just to explain the choice behind it. It was designed around SpiderMonkey Javascript VM, because at the time it was the only light, available on MIPS and standalone library for a Javascript VM. As we did lack the ressource to fully document and barely have the ressource to keep the binding up to date, it was decided to follow the C API. This give a way to directly get examples (like eweather in JS: http://code.google.com/p/freebox-elixir/source/browse/#svn%2Ftrunk%2Fapplications%2Feweather ) and docs from enlightenment.org. The script could only be distributed inside an edje file in a special eet section : elixir/main (other script could also easily be included in other section and requested dynamically from inside any other script). It was requested by a lot of devs to provide a kind of DRM to protect their apps code, so the elixir/main section was ciphered on the 'AppStore' server with a key only known by Freebox and deployed on the set top box that needed to request it every time they wanted to run it. Finally the last and most important point, elixir script should be always safe to execute. For that they didn't have a way to modify a file, only sqlite database was available for config file. As you can understand the entry level was high ! Really high ! EFL wasn't released at all at the start, Spidermonkey isn't packaged properly. Building Elixir wasn't really a trivial task, but devs quickly came with script and ppa that helped every one to setup a dev environment. People at the beginning complained that the SDK wasn't a more higher level JavaScript, but they quickly understand the reason of that decision and a few public (and some other private) JavaScript toolkit where written on top of it (http://code.google.com/p/freebox-elixir/source/browse/#svn%2Ftrunk%2Ftoolkit). As a matter of fact, most dev did what they wanted without really following any guideline :-) But due to the strict rules for publying apps most used edje (or at least learned how to put image inside an eet and open it with evas). The biggest complain wasn't about edje, but about the lack of an interface to easily create them (or at least understand the basic to get started). Editje was hard to get running and people want really a way to edit the code manually at some point. Another lack, was the fact that elementary wasn't available, due to a few reason (lack of a light theme and arrow navigation, nothing really impossible to add to elementary, but no ressource were dedicated to do that job). I have only one thing I really disliked, Spidermonkey API and release. They managed to provide something with less docs, with poorest snapshot (we can't call that release) and more breakage than EFL in the last 10 years ever did ! If I can only give you one feedback that you would remember from this long mail, avoid SpiderMonkey. And indeed v8 seems like the most interesting Javascript VM currently available. So after having maintained during that long an apps without a stable API, the first thing I can say is that you can avoid breaking Javascript apps even with unstable library API. You just need to force all Javascript apps to declare the version of the API they need at the beginning of their apps and adapt the exposed API depending on that. This is the mechanism that was used to avoid all EFL breakage, so Javascript apps from 2009 are still running in 2010 without touching anything on them (This is important when you have a small comunity and you don't want to loose dev and apps during it's life time). That's why elixir binding was written manually and not autogenerated, so that every function could be adapted depending on the change the API received (it also make it more easy to track the few entry point that could introduce security issue). The second biggest point is that you need a device with an easy way to securely deploy apps on them. It's what did make the difference between having a deployed SDK and that SDK behing used. It could be a device or E17 itself (or Enna, or Calaos, ...). If we want more developper writting apps, we need to think on how they can deploy their apps easily, because right now it require our users to compile them... I think it is possible to use Exchange for just that. With a new category for applications on exchange and a menu directly inside E17 itself to run local JavaScript apps and install new one. We could also add a JavaScript gadget that would contain itself inside an Ecore_Evas limiting side effect and making it possible to have safe gadget in E17 (and easily deployable). That's just my opinion on what we can do to improve the use of the EFL. If you have question, don't hesitate to ask :-) -- Cedric BAIL ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
