[Sugar-devel] HTML activities

[C. Scott Ananian]

On Thu, Jan 31, 2013 at 5:56 AM, Daniel Narvaez <dwnarvaez at gmail.com> wrote:

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

http://cscott.net/Publications/OLPC/sugarcamp-i18n.pdf has some thoughts
about multiple language support.  It can be a compelling feature for
bilingual communities; Sugar has so far only scratched the surface of its
potential.


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

There are two basic cases.  Where the correct behavior is to "do nothing"
on a non-sugar platform, you can implement the API as a fire-and-forget
postMessage.  ie:

Journal.recordActivityStart() = function() {
window.postMessage('org.sugarlabs.Journal/start', ...); }

This is harmless if no one is listening to the message.

In cases where you need two different sets of behavior, you will need to do
some feature probing.  Since window.postMessage is asynchronous, this is
tricky to do directly.  I'd suggest instead setting properties on the
window object.  For example: (pseudo-coding this a bit)

// note that all the APIs we add are under window.sugarlabs so that we
don't inadvertently conflict with other properties of 'window'
if (window.sugarlabs && window.sugarlabs.collaboration) {
   // XXX maybe we would also do some version checking here to ensure the
API was new enough (but not too new)
   exports.PeerToPeer = window.sugar.collaboration.PeerToPeer;
} else {
   exports.PeerToPeer = require('WebCollaboration'); //
reduced-functionality "pure browser" implementation, (eg using WebRTC)
}

I believe it is straightforward to add methods to the window object on
Android and when using Firefox add-ons (at least).
The alternative is doing a 'feature request' postMessage (asynchronously),
and then using a timeout to determine whether we get an affirmative answer
that the particular feature is implemented.  That would work fine, but it
seems clumsier than exporting a property on window.

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

It's actually not very hard: Firefox implements a new profile directory for
every installed web app.  We just install the webapp once on-line, and then
tar up the profile directory.  Installing the app offline is just untarring
the profile directory and tweaking the .js file which tells firefox which
profiles/webapps it has.  Firefox should have better mechanisms for this in
the future; http://mozbugs.github.cscott.net/ lists some bugzilla bugs
tracking useful features in this regard (for example
https://bugzilla.mozilla.org/show_bug.cgi?id=790456 ) -- but you don't have
to wait for upstream, you can make it work now.


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

I don't have a strong preference yet either.  There are also some
namespacing issues involved -- you might want to load the sugar apis from
some URL rooted at sugarlabs, for example:
  <script src='http://sugarlabs.org/api/1.2/peer2peer.js'>
This would be put in the offline cache along with the other files, of
course, but it specifies a canonical source for the library and makes it
easy to distribute API-compatible updates to connected devices.


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

https://github.com/cscott/skeleton-addon-fxandroid/tree/jni for just the
JNI binding skeleton,
https://github.com/cscott/intent-addon for a full plugin built from this
skeleton.
(see in particular
https://github.com/cscott/intent-addon/blob/master/lib/main.js which does
low-level binding of the Android Intent API)


> Feel free to get started on the collaboration API :)
>

I am going to attempt to draft a simple multiplayer game using JavaScript
bindings to the Android Wifi Direct APIs.  This should inform the design of
the collaboration API, as well as point the way to a
JavaScript-with-native-bindings implementation of the Sugar network view.
(Reading
http://developer.android.com/training/connect-devices-wirelessly/nsd-wifi-direct.htmlreminds
me of how the sugar network and friends view is supposed to work!)
  --scott

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