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

[Daniel Narvaez]

Hi William,

can you be more specific? Why do you think it's too taxing? Did you profile
it?

I'm not sure what you mean with instance, but it would be one Chromium
window per activity.

In theory I wouldn't expect a big difference. Chromium is built on the top
of WebKit.. It's replacing the javascript interpreter and the network stack
but I can't see those affecting memory usage that much. Compared to WebKit1
there might be some overhead caused by the multi process architecture, but
then we are moving to WebKit2 which is also multi process.

Unfortunately it's hard to measure Chromium memory usage because of the
multiple processes. I tried using the PSS script here

http://emilics.com/blog/article/mconsumption.html

That actually would seem to indicate Chromium uses less memory than
WebKit1. Though I wouldn't be surprised if it was underestimating it in
some way. I can spend some time figuring out how to profile it properly but
I would like to understand why and how you think it would be heavier
before...

Thanks!

On 13 April 2013 06:29, William Orr <will at worrbase.com> wrote:

> I'm pretty new to the mailing list and the project, but I'm pretty sure
> that starting a new Chrome instance for every launched activity is far too
> taxing for the XOs.
>
> I think that Lionel's idea of using a Python activity that uses the WebKit
> WebView is a much, much better solution.
>
>   lionel at olpc-france.org
>  April 12, 2013 4:36 PM
>
> ** **
>
> Hi Daniel,****
>
> ** **
>
> Impressive idea with a cool architecture. BTW, to be honest I think it’s…
> too complex.****
>
> Why not just create a standard Python activity template that call the
> WebKit WebView? Like we do today.****
>
> ** **
>
> But maybe I miss something or maybe we don’t speak of the same thing?****
>
> When I wrote the GSoC proposal, I think to a two steps process.****
>
> ** **
>
> What I call the “first step” is just to create an activity template with a
> full screen WebView control and a Sugar to JavaScript.****
>
> So it’s like my work on Enyo today but:****
>
> -          With a better way than “console-message” to communicate
> between JavaScript & Sugar,****
>
> -          With a JavaScript/CSS framework to reproduce in HTML5 the
> Sugar Look&Feel and sugar.graphics stuff,****
>
> -          With a JavaScript framework that allow calling all Sugar
> features (telepathy, data store, l10n, drag&drop, …).****
>
> We could probably do all these things without lot of change on current
> Sugar implementation and current Sugar activity way of working. In my mind,
> this could work even on Sugar 0.96-0.98 without any change!****
>
> ** **
>
> Except if I’m wrong, what you’re currently describe is the “second step”:
> upgrading Sugar to support directly HTML5 activities.****
>
> In this second step we could imagine that Sugar will be very different
> than today (may be an Android layer or a Chromium layer) and that no
> current Python activities will work on it. BTW HTML5 activities built with
> the “first step framework” should be very easy to adapt: just need to
> change the JavaScript framework implementation to use natives features
> instead of Sugar Python features (for example: call HTML5 storage instead
> of Datastore storage) and remove the XO Manifest/Package. I do like your
> architecture proposal for this second step but it’s difficult to me to
> think to this second step without we’ve got a more precise view of the
> first step.****
>
> ** **
>
>                 Lionel.****
>
> ** **
>
> ** **
>
> ** **
>
> *De :* Daniel Narvaez [mailto:dwnarvaez at gmail.com <dwnarvaez at gmail.com>]
> *Envoyé :* jeudi 11 avril 2013 21:52
> *À :* sugar-devel at lists.sugarlabs.org
> *Cc :* Lionel Laské
> *Objet :* Chromium integration inside the sugar shell (was Re: Kicking
> off HTML5 activities work)****
>
> ** **
>
> 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.*
> ***
> _______________________________________________
>
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>   Daniel Narvaez <dwnarvaez at gmail.com>
>  April 11, 2013 3:52 PM
> 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.
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>


-- 
Daniel Narvaez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20130413/2991a531/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20130413/2991a531/attachment-0001.jpg>