Thanks Daniel. Lots of interesting points here!<br><br>On 17 April 2013 16:26, Daniel Drake <span dir="ltr"><<a href="mailto:dsd@laptop.org" target="_blank">dsd@laptop.org</a>></span> wrote:<br><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So the real benefit of the Chrome thing is the system integration? Is<br>
that something really needed for Sugar? It would be necessary if we<br>
were to port *all* Sugar activities to javascript, but I am not sure<br>
if that is our goal. There are certainly a lot of things that can be<br>
done without such system access.<br></blockquote><div><br>My personal *long* term goal is to port the whole thing to javascript. That probably explains the directions my research is taking.<br><br>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.<br>
<br>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.<br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

I also have some other concerns about using Chrome as a backend<br>
(please correct any inaccuracies):<br>
<br>
1. We have to accept all constraints of Chrome - both present and<br>
future. We have found two already: the challenges of handling of<br>
multiple versions, and the challenges of making this system work<br>
without having chrome running in the background all the time.<br></blockquote><div><br>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. <br>
 </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
2. From my limited understanding, Chrome/Chromium is technically an<br>
open source project, since code is made available, but does not fit<br>
under many more definitions of "open source project". It's not<br>
something that is developed in the open with decisions run past the<br>
community etc. That doesn't fit the Sugar model very well.<br></blockquote><div><br>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.<br>
<br>Firefox is probably the most open but even there, the mess they did with embedding isn't making me much comfortable. <br><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

3. I see this project as a way of taking us closer to Sugar (in some<br>
sense) on Android. Can Chrome webapps work as first-class citizens on<br>
Android?<br></blockquote><div><br>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.<br><br>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.<br>
<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im"><br>
> (Hopefully they will some day converge between browsers!).<br>
<br>
</div>There is already convergence in the "utility function" part of such<br>
APIs - for example you can take qooxdoo and use all of its API on any<br>
browser.<br>
<br>
I think it is only a matter of time until some kind of system emerges<br>
that provides a browser-independent API to low level system functions<br>
as well. (or maybe we already have that: gobject-introspection, which<br>
can be used in javascript?)</blockquote><div><br>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.<br>
<br>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.<br></div></div>