[Sugar-devel] A prototype of SugarWeb / SugarAndroid - Technical questions

[Manuel Quiñones]

2013/11/14 Daniel Narvaez <dwnarvaez at gmail.com>:
> Hi Manuel,
>
> current lack of standardization aside, there is another pretty fundamental
> security related issue here, that we probably need to make a conscious
> decision about.
>
> Those kind of API are usually associated to the web browser's web
> application frameworks, often requiring certain permissions. Thus the
> application launcher (and installer) are implemented in the browser itself,
> not in the content. So to get a Sugar like launcher (and "window" manager)
> you would need to patch or customize the web browser. That makes it harder
> to run Sugar, you need to install an application rather just going to a
> website, and I'm not too convinced we have resources to develop it anyway.
>
> Another possibility for us would be to this kind of stuff server side, at
> least when it's not hardware related (settings, journal etc). That doesn't
> make the security issue go away, but maybe there are ways we can provide
> that security through the normal client/server interaction.
>
> The situation of the various Sugars we have been discussing is pretty
> different in this regard
>
> * Sugar on Linux. We actually control the launcher there, though WebKit
> doesn't have a web application framework we can use. When these API will
> standardized I suppose we could hope generic support for one will be added.
> For now, one has been implemented in Chrome, so on an higher layer that we
> can't use.
> * Sugar on Android. If we wanted I guess we could add support for these an
> API in the native wrapper. The implementation would be on us though.
> * Sugar on a Web site. Well, there is no web application launcher by
> definition there.
>
> My feeling is that the most pragmatic approach would be to implement
> settings, datastore and similar APIs on the server. We can either use the
> current websocket protocol or implement something more web friendly as it as
> been suggested (for example http POST to store files). On Linux we can run
> the server locally. Sugar on Android is just a wrapper loading Sugar on a
> Web site from the remote server.
>
> That said I don't think there is a perfect solution given our resources and
> honestly I'm not really sure which of the realistic options is the best one.

Absolutely.  I don't have the answer too.

In the long term, I think we should keep an eye at mozilla's WebAPI.
They are the ones doing a complete web OS. But for a current,
realistic approach, I agree that a server might suffice for the non
hardware settings.

-- 
.. manuq ..