At the risk of diverting you guys from your good work, let me add a few related thoughts: 1) I think the core of this "new API" focus should be on the question: "what are the essential parts of the Sugar experience"? I would like these roughly as follows (you may have other ideas): a) the journal b) collaboration c) consistent look and feel ("visual design language") / toolbar, etc d) "view source" e) polyglot support First, decide among yourselves what the "core sugar experience" is. Then I would encourage the creation of separate focused APIs / libraries for these main components, not rolling them all together into a big "sugar" tarball. That way apps which want (say) just the sugar look and feel can import a package which does "just the UI widgets" without dragging in other stuff (and even before, say, collaboration is finished). These APIs should be written in a language-independent manner (think about gobject) so that the same basic APIs can be used on multiple platforms. This will make it easier to write a "sugar activity" (meaning support for a-e) which is Android-native, or (my preference) a web activity which supports a-e on a desktop web browser, an xo running sugar, and an android device. 2) Ideally these libraries would all be optional; that is, there is a "pure web" implementation/fallback available, which is overridden when there is platform-specific support. I should be able to run a sugar activity on a desktop web browser, but I might not get (for example) journal support -- or the journal support will be via a <a href="http://journal.sugarlabs.org">journal.sugarlabs.org</a> server somewhere. If I run the same web activity on an XO, there are local hooks (think "a plugin") that allows me to use the "real" journal. If I run the same activity on an Android phone, the plugin might use a special Android implementation of the journal. Write good APIs, and allow multiple implementations. 3) I think embedding a web server is probably the wrong way to go. HTML5 has robust offline application support. If you write an offline web app, it runs the same on an XO, a desktop browser, and an android phone. I recommend Firefox/Android for running webapps on Android. The Nell's Balloons and Nell's Colors activities I've written are good examples of offline web apps; there's also an offline Wikipedia reader. The interesting technical challenge is to prepopulate the offline web cache with the appropriate files when the activity is installed, but this is pretty straightforward profile hacking; I can tell you how I do it for Firefox/Android if there is interest. 4) I recommend adoption of a component strategy. Something like <a href="https://github.com/component/component/wiki/Components">https://github.com/component/component/wiki/Components</a> although <a href="http://jamjs.org">jamjs.org</a> and <a href="http://volojs.org">volojs.org</a> also look very reasonable. But try to keep dependencies lightweight. You want just enough to provide for good namespacing. 5) I have written a plugin for Firefox/Android which allows access to Android' native Java APIs from web app code. This is a good way to implement (for example) a collaboration API on top of Android's native peer-to-peer wifi APIs. I'm interested in working on this. 6) The webkit web inspector is the best implementation of "view source" that I have yet seen. Try to find ways to leverage that --- ie, avoid packaging strategies that bundle or obfuscate the code. I believe this is also the strongest argument against the use of CoffeeScript for Sugar, at least at the library level. (The "source map" feature of webkit helps to some degree, but it's still not as clear as viewing straight java script.) 7) Writing fluent javascript isn't about syntax, believe it or not. You can get most of the "good stuff" via good use of the native methods. For example, Array.forEach is an excellent substitute for "for each" syntax. In fact, I've done quite well writing in a deliberate *subset* of Javascript (see <a href="http://cscott.net/Projects/TurtleScript/">http://cscott.net/Projects/TurtleScript/</a>) in an effort to make my code easier to understand and visualize using block-based editors. That said, I expect 90% of your work will be writing good interfaces and APIs. If this is done, it will be easy to write clean readable activities on top of the APIs, even if the actual implementation of some of the APIs gets messy. Hope this is helpful. I think it would actually be useful to have a summit of some sorts around these issues. As you can tell from the above, I believe that a good implementation of web activities for Sugar is also important for the continuation of the Sugar ideas on other platforms, like desktop and android. So this is good fundamental work. It's good to see how much progress you guys have already made. --scott -- ( <a href="http://cscott.net" target="_blank">http://cscott.net</a> )