[Sugar-devel] Kicking off HTML5 activities work

Daniel Narvaez dwnarvaez at gmail.com
Sun Apr 7 18:39:34 EDT 2013


Hello,

when Simon is back, it would be good to have an IRC meeting to kickoff the
work on HTML5 activities. I generally prefer mailing list discussions, but
in this case I think it would be useful to chat about it to start things
off...

Anyway I've been researching more and I thought I'd post about what I have
in mind at the moment.

I think if we are able to jump on one of the existing web applications
trains it's going to be much better than doing our own thing based on
Webkit embedding. All the major browsers are implementing their web apps
stuff at a level which is higher than their embedding frameworks. On the
long term, I don't think it's sustainable with our scarce resources to
maintain an embedding + web apps framework. Also it would be great to be
fully compatible with existing apps.

With Agora I've been exploring the Firefox OS framework. There are a lot of
things I like in it but I don't think it's viable for Sugar on the short
time because, being fully web based, it would require to rewrite the shell
and all activities in HTML. It's also not particularly mature, for example
multiple processes works only on Android at the moment.

In the last couple of days I've been looking at Chromium and I've found
several good things

* The web apps API seems pretty mature and well documented.
* Their approach with ChromeOS is to have a native application launcher and
window manager (aura). It's a cross platform, custom thing, so I don't
think we could adopt that layer. But still it's more similar to what we
need compared to Firefox OS.
* Chrome already has an application mode, activated by command line
switches, which hides the browser chrome.
* The extensions and applications API seems to provide everything we need.
* The multiple process framework is certainly more mature then Firefox and
perhaps then WebKit too.

So here is more or less what I have in mind

1. Add support for Chrome web apps to Sugar.

We could start by adding a native "App store" activity, which would
basically be just a (UI less) Chrome browser window, pointing to a website
hosting web apps. The installation would be all managed by Chrome itself.
The sugar shell would communicate with Chrome through an extension to get
the list of installed activities, to request launching and uninstalling
them. We should be able to do that with these extension APIs:

http://developer.chrome.com/extensions/management.html

http://developer.chrome.com/extensions/runtime.html#method-connect
http://developer.chrome.com/extensions/examples/extensions/native_messaging.zip
(There is a connectNative method which is not yet documented. Rather than
connecting to another extension, it connects to a native process and
communicates via standard input and output).

In the UI web apps would just look like normal activities. We need to
figure out the window manager bits which might be a bit tricky but I'd
think possible.
We need a way to start Chrome without windows to be able to get a list of
installed applications. I have not investigated it but I suppose at worst
we would have to add a command line option. Or... we could keep the store
always running.

2 Implement html/css/javascript UI controls following the HIG.

I'm pretty happy with the approach I've taken in Agora

https://github.com/ayopa/xi-graphics
https://github.com/ayopa/xi-artwork
https://github.com/ayopa/xi-activity

3 We could expose datastore access through the html5 filesystem API. The
application would request persistent storage, save both data and metadata
there and we would then somehow put that in our datastore.

http://www.html5rocks.com/en/tutorials/file/filesystem/

4 We could expose collaboration using WebRTC.

https://hacks.mozilla.org/2013/03/webrtc-data-channels-for-great-multiplayer/


I have not really explored 3 and 4 much. The point is that if we can use
existing APIs rather than cooking up our own, it's of course better.
I think 1 and 2 can be worked on in parallel. Even if we find that we can't
really do 1, the work on 2 would not be wasted because it will be fine on
other browsers too.

Anyway just brainstorming here! It would be useful to have more people
investigating this stuff. Or starting to write more of the UI bits :)

-- 
Daniel Narvaez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20130408/832f9f72/attachment.html>


More information about the Sugar-devel mailing list