[Sugar-devel] HTML activities

[Daniel Narvaez]

On 30 January 2013 17:35, C. Scott Ananian <cscott at laptop.org> wrote:
> 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

Yeah I pretty much agree about a-d like, I suspect, a lot of people on
this list. I'd probably move b a bit higher, but not quite sure where.
I have never thought about e.

> 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).

Yeah, influenced also by my recent nodejs hacking, I think extreme
modularity here is a good idea.

> 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.

I still need to think it all through, but with the more detailed
explanation in the other email, I like the basic concept.

> 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.

I like the idea of a full fallback implementation a lot. Do you have
any idea on how to implement the fall back mechanism? Anything better
than

<script src="nativelib.js"></script>
<script>
    some_lib_method || document.write('<script src="fallbacklib.js"></script>')
</script>

> 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.

I think you and Lionel almost convinced me on this. I need to look
more into the offline web app stuff into html5. An explanation of how
you implemented the offline web cache would certainly be interesting.

> 4) I recommend adoption of a component strategy.  Something like
> https://github.com/component/component/wiki/Components although jamjs.org
> and volojs.org also look very reasonable.  But try to keep dependencies
> lightweight.  You want just enough to provide for good namespacing.

Yeah, the namespacing issue was the first thing I thought about when
getting into the js code. The package manager aspects of these
frameworks is also interesting because it seems like we will need to
include our js library directly in the app, if nothing else as
fallback.

I didn't really do a proper comparison of the three frameworks but a
couple of things I noticed... Component *seems* to depend on github?
I'm not sure I like that. Volo is suggested for Firefox OS
applications.

> 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.

Link to the plugin?

Feel free to get started on the collaboration API :)

> 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.)

Very good point.