[Sugar-devel] HTML activities

[C. Scott Ananian]

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 journal.sugarlabs.org 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
https://github.com/component/component/wiki/Components although jamjs.organd
volojs.org 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 http://cscott.net/Projects/TurtleScript/) 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

-- 
      ( http://cscott.net )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20130130/f65a7e4b/attachment-0001.html>