[Sugar-devel] Chromium integration inside the sugar shell (was Re: Kicking off HTML5 activities work)

[Daniel Narvaez]

Hello,

I spent some time today thinking and experimenting with Chromium
integration and I have a more detailed plan to propose now.

There is an important premise to be made. In both Chromium and Firefox OS,
application's installation is very much in the hands of the web browser. It
happens as the result of a user clicking on a button, inside a web store.
Chromium is a bit more flexible but the other possibilities are basically
just developer tools.
I think this limits our possibilities a lot. We need to use the browser
applications management, rather then installing applications ourselves and
then launching them with some command line option. Of course Chromium is
open source and we could develop the stuff which is missing. But, in my
opinion it's just too much work and it's going to be a pain to maintain in
the future, core developers are not going to care about it, given it's not
important for their products.

That said, I think I mostly figured out a plan to integrate with Chromium
web apps management, without having to write a lot of code.

* Chromium is started up with the sugar session, using the
--no-startup-window, to make it invisible. The sugar extension has a
"background" permission, which will keep it running even with no windows.
* The extension runs a python script, using chrome.runtime.connectNative.
Communication uses json-rpc wrapped in the message protocol supported by
the extension. The python script fetches the list of installed activities
(as exposed by chrome.management.getAll) and listen to changes.
* The python script exposes a dbus service, allowing the sugar shell to get
the list of installed applications and to display icons for them in the
home. We use GIOChannel to read stdin, so that we don't block and integrate
with the glib mainloop.
* When the user click on an icon, a LaunchApplication is called on the dbus
service, which proxies it to the extension, which launches the application.
We will probably need a trivial patch to chromium to start it without UI.
There is already a define for chromeos, but it's a compile time thing (in
extension_prefs.cc, GetLaunchContainer).
* The shell notices that a new window has been opened and associates it
with the application information. This allows to activate and close the
activity as necessary.
* Uninstalling an activity works in the same way as launching. Shell ->
python script -> extension.
* Implementation of collaboration and datastore libraries could also be
based on the python script messaging.

I implemented (badly) a good part of this and I didn't find fundamental
problems with it. Except for one, which is not specific to this plan. Sugar
supports multiple instances of the same activity, web application
frameworks doesn't. How are we going to deal with that? I haven't thought
much about it yet, but it seems something we want to be very clear about.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20130411/59b7978a/attachment.html>