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

[Gonzalo Odiard]

Let me understand this, when you talk about single-origin or
multiple-origin,
is only related to the LocalStorage access or imply something more?

Gonzalo




On Thu, Nov 14, 2013 at 7:50 PM, Daniel Narvaez <dwnarvaez at gmail.com> wrote:

> 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>
>>
>>> 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 ..
>>>
>>
>>
>
> --
> Daniel Narvaez
>
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20131114/c83b219b/attachment-0001.html>