[Sugar-devel] Kicking off HTML5 activities work

[Daniel Narvaez]

On 9 April 2013 17:56, Manuel Quiñones <manuq at laptop.org> wrote:

>
> > 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).
>
> Interesting.  Will this make the webapp activity installed so it
> appears in the spiral already?  At first glance it looks like a big
> task for the first step. But on the other hand, going through all this
> process will make us identify any issues.  This could be an
> "activities store" + "hello web" activity.
>

Yeah, exactly. It doesn't actually need to be the first step, we can start
developing activities inside Chrome even without this. But at some point we
need to do it to figure out the issues.  The initial implementation is
hopefully not going to be a huge amount of work, I'm planning to give it a
try, perhaps after the IRC meeting.


> We can start using the term "webact" meaning "web activity" instead of
> "webapp" :)
>

:)


 We could also look at what Ubuntu is doing regarding this and other
> webapp things .  They have integration with both Firefox and Chrome:
>
> https://launchpad.net/webapps
> http://developer.ubuntu.com/resources/technologies/webapps/
>
>
Great find! We should keep an eye on that.

They have patches we might need, like one to run chrome without any UI. I
thought we could use --kiosk, but if they didn't  use it maybe there is
something wrong with it. Upstreaming that kind of stuff is going to be much
easier if more people are interested.

Their approach is very similar to what we are planning. They have a C
library with a dbus daemon

http://bazaar.launchpad.net/~webapps/libunity-webapps/trunk/files

They are using npapi to bridge to the native libraries. They seem to have
bits of generic code which might be interesting for us

http://bazaar.launchpad.net/~webapps/unity-chromium-extension/trunk/files

I'm not sure how using npapi compares to the native messaging stuff.
Something to think about anyway.

As I said, whenever we can figure out how to use existing APIs (even if
chrome/firefox specific) it's much better in my opinion. But,
realistically, in some cases we will need our own custom APIs.

> 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/
>
> Hmm looking at that tutorial, seems like each webapp can access it's
> own sandboxed filesystem.
>

Yeah, so the idea would be the sandboxed filesystem to correspond to a
journal entry. For example, we could have applications write two files
there, data and metadata.

I have not looked how, implementation wise, the sandbox could be turned
into a journal entry at all yet, it's just a vague API level idea :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20130410/5e955fe9/attachment-0001.html>