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

[Daniel Narvaez]

Thanks Daniel. Lots of interesting points here!

On 17 April 2013 16:26, Daniel Drake <dsd at laptop.org> wrote:

> So the real benefit of the Chrome thing is the system integration? Is
> that something really needed for Sugar? It would be necessary if we
> were to port *all* Sugar activities to javascript, but I am not sure
> if that is our goal. There are certainly a lot of things that can be
> done without such system access.
>

My personal *long* term goal is to port the whole thing to javascript. That
probably explains the directions my research is taking.

I think to be meaningful Sugar requires full control of the OS, as in its
original vision. And to be relevant it needs to run also on mobile
hardware. These days a cross platform toolkit seems the only way to try and
achieve those goals without developing hardware and OS.

The model I have in mind here is Firefox OS, which is basically an html
layer on the top of the Android system level components.


> I also have some other concerns about using Chrome as a backend
> (please correct any inaccuracies):
>
> 1. We have to accept all constraints of Chrome - both present and
> future. We have found two already: the challenges of handling of
> multiple versions, and the challenges of making this system work
> without having chrome running in the background all the time.
>

Sure. Though I think we will have to make some compromises somewhere. Both
because we don't have the resources to develop our own thing and because of
cross platformness.


> 2. From my limited understanding, Chrome/Chromium is technically an
> open source project, since code is made available, but does not fit
> under many more definitions of "open source project". It's not
> something that is developed in the open with decisions run past the
> community etc. That doesn't fit the Sugar model very well.
>

But is WebKit so much better? For example the WebKit2 decision _seems_ to
have been made by Apple engineers without even talking to major
contributors. The gtk bits are maintained the way we would like them to
but... I'm not sure that applies to the rest of the codebase.

Firefox is probably the most open but even there, the mess they did with
embedding isn't making me much comfortable.

3. I see this project as a way of taking us closer to Sugar (in some
> sense) on Android. Can Chrome webapps work as first-class citizens on
> Android?
>

That's actually something I was thinking about. I have the feeling they
cannot at the moment, but it would be useful if someone with an Android
phone could confirm.

It doesn't seem like a point against using Chrome in Sugar though, we
wouldn't be any better off with WebKit, rather it would be in point in
favor if it was possible.


> > (Hopefully they will some day converge between browsers!).
>
> There is already convergence in the "utility function" part of such
> APIs - for example you can take qooxdoo and use all of its API on any
> browser.
>
> I think it is only a matter of time until some kind of system emerges
> that provides a browser-independent API to low level system functions
> as well. (or maybe we already have that: gobject-introspection, which
> can be used in javascript?)


Yup. But I don't think this kind of system will be implemented as a
cross-browser library. The browsers will agree on an API and each of them
will have its own implementation of it. Also, they are currently being
implemented at higher level then embedding and I doubt there will be any
incentive to push them down later.

The situation I want to avoid is to have to do our own implementation of
these interfaces. If there is a plan to address that issue, then using an
embedding widget is cleaner then a full browser, of course.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20130417/b6276996/attachment-0001.html>