[Sugar-devel] Firefox and html activities

[Daniel Narvaez]

Another factor in memory usage of b2g and android is likely the absence of
XUL. And possibly other optimisations which are not present in the Firefox
build. We need to investigate what it would take to enable these in
webapprt Linux build.

On Tuesday, 5 February 2013, Daniel Narvaez wrote:

> I'll start with a very general consideration. I'm more and more convinced
> we should not just add support for html5 but build directly on the top of
> web applications, as they are emerging both in the Mozilla and in Chrome
> ecosystems. This means no native/html activities mashups and more
> importantly the same kind of logic for installation, distribution etc. I've
> not fully rationalised this assumption yet but, some advantages I see with
> it
>
> * Sugar activities will run wherever Firefox (or Chrome) runs. Firefox web
> activities will run in Sugar.
> * No adaptation necessary, no wrappers, nothing.
> * It will be possible to submit Sugar activities to, say, the Firefox
> store, giving them more visibility.
> * We will not have to maintain browser embedding code, which can be really
> painful
> * We will be able to use new APIs which are being developed as part of
> efforts like Firefox OS.
> * Developers with experience with web apps will know what to expect.
>
> Now the ironic part is that while it would be pretty straightforward to
> get this going on desktops and on Android, it looks more tricky in Sugar. I
> investigated using Firefox and these are the issue I run into.
>
> * No support for offline, browser-less installation. It's actually mostly
> there for b2g but it only applies to a set of zip files which are found on
> the first startup.
> * No support for webapps addons (needed to interact with the sugar
> services, datastore for example). According to a developer comment on a bug
> report it is planned for the future though.
> * Necessity to replace Browse with a Firefox based webapp, to integrate
> with the normal installation mechanisms.
> * Very high per process memory usage. I think it's > 50 MB per activity. I
> have not tested but I suspect b2g (and perhaps Android) gets around this
> with electrolysis child processes, but Mozilla is not currently working on
> electrolysis for the desktop browser.
>
> Now the first two are probably solvable nicely by working a bit upstream
> and has work arounds on the short time (not quite sure about addons, but I
> have some good hopes).
> The need to replace Browse is a bit scary. I hoped we could take an
> incremental approach and would not need to rewrite any native activity. I
> suppose we could have a webapp store activity instead.
> Memory is a blocker I'd say, even if not an immediate one, we would want
> it solved before we can start using webapps in the field. I've not looked
> into it much but as far as I understood electrolysis is on hold mainly
> because of compatibility with existing (non jetpack) plugins. So I wonder
> if you could enable electrolysis at build time and have it working for
> webapp rt. After all it works in b2g which is not hugely different.
>
> I'll keep investigating this direction and update the list as I make
> progress.
>
>
>
> --
> Daniel Narvaez
>
>

-- 
Daniel Narvaez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20130206/1205f541/attachment-0001.html>