[Sugar-devel] Firefox and html activities

[Walter Bender]

On Wed, Feb 6, 2013 at 6:50 AM, Daniel Narvaez <dwnarvaez at gmail.com> wrote:
> Duh, s/aurora/gaia. I keep mixing those up.
>
> On 6 February 2013 11:47, Daniel Narvaez <dwnarvaez at gmail.com> wrote:
>> Hello,
>>
>> I just realized that the current Firefox OS architecture looks perfect
>> for our purpouses. It's pretty well documented here
>>
>> https://wiki.mozilla.org/B2G/Architecture
>>
>> In short
>>
>> * gonk. The base OS. Kernel, network management...
>> * b2g. Analogous to a web browser, A single window which can run
>> multiple webapps, each in it's own process.
>> * aurora. The UX, as a collection of webapps. There is also an
>> extension used only for debugging, but it proves that extensions works
>> there which is important for us.
>>
>> I can think of two main ways we could base our webapps on this. One
>> blue sky the other more realistic and useful in the short time.
>>
>> # Common
>>
>> We don't need gonk. Our base system is just a normal Linux
>> distribution, with a few sugar specific services, datastore and
>> collaboration comes to mind.
>>
>> We use b2g as provided by upstream. If we need to make changes they
>> have to be submitted to mozilla. This ensures we don't have to fork
>> anything with the associated maintenance costs. Note that b2g already
>> runs on a desktop just fine.
>>
>> We load an extension which interacts with our own system services.
>>
>> # Blue sky
>>
>> We replace aurora completely with out own set of web apps,
>> specifically written for sugar, using the sugar-html js (graphics,
>> datastore, collaboration...). The shell UI components (home, frame...)
>> are also part of a webapp, as is window management.  Native apps are
>> not supported.
>>
>> # Realistic
>>
>> We run b2g inside sugar. The shell talks with the extension to get a
>> list of installed and running web activities to display in the home,
>> to launch them, to switch to them as required. It brings up the b2g
>> window when activating one of the webapps and so on.
>> Most of sugar is still made of native apps, but it's possible to start
>> writing web activities.
>>
>> # From realistic to blue sky
>>
>> There are possible variations in middle.
>>
>> * Native activities might be wrapped into webapps using GDK Broadway

FWIW, we played with this a while back and it does work. There were
bandwidth considerations and we didn't characterize the performance
implications for XO class hardware...

>>
>> http://developer.gnome.org/gtk3/3.3/gtk-broadway.html
>>
>> This would allow to get rid of the native sugar shell without
>> completely preventing native activities (of course non-gtk activities
>> would not work). It could be an intermediate step or could be the
>> final target if we decide providing some kind of native activities
>> support is important.
>>
>> * Web applications which are not designed for sugar could be part of
>> our set of core activities.
>>
>> * Parts of the shell could start to be ported to webapps gradually.
>>
>>
>> I'm pretty excited about this, I don't see particular roadblocks. I
>> have not investigated very deeply yet though, I might find them (or
>> you might!), let's see :)
>> It's nice because in principle it doesn't require any heavy or non
>> upstreamable mozilla patching. It gives us access to all the stuff
>> mozilla is developing for webapps. And it allows a smooth transition
>> from the current architecture.
>
>
>
> --
> Daniel Narvaez
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel



-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org