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

[Daniel Narvaez]

Re server side. It would be necessary only with multi-origin. If you go
with single-origin there is no point.

I'm honestly undecided between single and multi origin. I think multi
origin would be doing it right, but then I don't have a realistic way to
implement it that I'm really happy with. So...

In any case I think it's more important to write a few cool activities and
have an UX we can proudly demo on Web/Android at the moment. I brought
up these issues because I think they are pretty fundamental and we should
be conscious of the approach we are taking but... we don't necessarily need
to find the perfect solution for them now.

On Thursday, 14 November 2013, Lionel Laské wrote:

>
> My answer is: we should go to simplicity.
>
> Regarding the one or many origin. I think, one is better. It allow sharing
> LocalStorage between activities which simplify a lot.
> Security is not an issue, I don't see any risk of hack here :-) We should
> just indicate naming rules to avoid collision.
> Regarding running of activities, my idea was that new activities should be
> deployed locally (no remote execution). By the way, it don't forbid us to
> have a cloud view in the journal where remote activities could be listed
> then retrieve and deploy locally.
>
> Regarding client/server approach, I'm agree for Sugar on Linux but I don't
> understand why we need the same approach for Sugar Android and Sugar Web.
> Once again Sugar Web should be able to work alone without depending on
> server. So Sugar Android will not need to integrate a server neither depend
> to be connected. The lower the prerequisites is, the better it will be easy
> to port it on any platform (from a browser to Android, iOS, Windows 8...
> :-).
> To say it differently: if the server side is here only because a
> multi-layer architecture is better but there is no real need to have a
> server side, we should do without server side.
>
> Regarding API to access to the device, because nothing standard exist in
> web, we have to wait and just ignore it. For Android, we could use PhoneGap
> API that allow to do everything (Camera, Compass, Geolocation, ...).
>
> Do I miss something ?
>
>              Lionel.
>
>
>
>
> 2013/11/14 Manuel Quiñones <manuq at laptop.org <javascript:_e({}, 'cvml',
> 'manuq at laptop.org');>>
>
>> 2013/11/14 Daniel Narvaez <dwnarvaez at gmail.com <javascript:_e({},
>> 'cvml', '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 ..
>>
>
>

-- 
Daniel Narvaez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20131114/5c0a8f62/attachment.html>