On Tue, 7 Jun 2011 11:44:45 +0200 Cedric BAIL <cedric.b...@free.fr> said:
> 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. interesting fact here is how appstore (universal app delivery/publishing mechanism) was the things that increased developer numbers. devs hate doing delivery/sales. they want to develop. this shows here. i'd love to see us in e18/e19 land come up with a "ships with e" app delivery mechanism. as such something like elev8 totally simplifies this as it removes dependencies. if u have elev8, it will work. thats it. i'd love it that e comes with the "app store" built in - a simple browser, downloader and a very very very simple way to upload new apps (publish). right now e.org's screenshot page is working well. i'd work on the same model. no registration. just upload blobs. server-side blobs are verified for correctness and categorised and indexed. clients just request new indexes and metadata and when they want it - the actual app bundle. > 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 last i heard v8 only got mips support recently too. > 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 that makes sense. > (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. interesting. but the js itself is "unencrypted on the set to box" right? so they cared only about the distribution being drm'd/encrypted or they want it even encrypted locally - eg if user had file access to the decrypted data? > 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). understood why elixir is where it is. and what mike is doing with elev8 is from day 1 doing that high level api baked right into it. so its like taking elixir to the "next level". > 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). sure. editje is still there for edje, but even it could do so much more. > I have only one thing I really disliked, Spidermonkey API and release. i've looke3d even at the latest release moz did a month or so ago. even it wasnt that great. i tried a port of elixir to it but it ended up with a segving bit of fun. :( > 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. i can see. spidermonkey has gone and broken lots of apis it didnt need to. it's whole build tree isnt in the best of shape and install setup isnt fantastic either. > 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 i really like this idea. it's awesome. in fact enforcing it would be good. eg if the js engine starts executing any bindings at all without a version decl, it should bitch and tell the dev to "add this line at the top" (generate a print with some js that declares the current engine version so the dev basically declares they are using the current version thats in front of them). > 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). makes sense. > 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 as per your appstore point above. > 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. agreed. though i'd say this is more likely for e18, but if elev8 is usable as a shared library, it can be plugged into e17 itself even in certain circumstances. but forget extending e itself via js for now. just worry about writing useful apps/utilities/etc. then make it easy to publish and download (appstore) and we can include the appstore thing with e. if its generic enna and calaos can also include it. this is where we may need a simple standard for "add canvas objects to existing win/canvas someone else made" which is the diff between writing your own app (you make the window) vs plugging into someone elses. for now worry about the app case and the plugin case later. > 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 -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
