<div dir="ltr">Let me understand this, when you talk about single-origin or multiple-origin, <div>is only related to the LocalStorage access or imply something more?</div><div><br></div><div>Gonzalo</div><div><br></div><div>
<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Nov 14, 2013 at 7:50 PM, Daniel Narvaez <span dir="ltr"><<a href="mailto:dwnarvaez@gmail.com" target="_blank">dwnarvaez@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Re server side. It would be necessary only with multi-origin. If you go with single-origin there is no point.<div><br></div>
<div>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...</div>
<div><br></div><div>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.</div>
<div class="HOEnZb"><div class="h5">
<div><br>On Thursday, 14 November 2013, Lionel Laské wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><br></div>My answer is: we should go to simplicity.<br>
<br></div>Regarding the one or many origin. I think, one is better. It allow sharing LocalStorage between activities which simplify a lot.<br>
</div><div>Security is not an issue, I don't see any risk of hack here :-) We should just indicate naming rules to avoid collision.<br></div>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.<br>
<br></div><div>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... :-).<br>
</div><div>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.<br><br></div><div>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, ...).<br>
</div><div> <br></div>Do I miss something ?<br><br></div> Lionel.<br><br><div><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/11/14 Manuel Quiñones <span dir="ltr"><<a>manuq@laptop.org</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2013/11/14 Daniel Narvaez <<a>dwnarvaez@gmail.com</a>>:<br>
<div><div>> Hi Manuel,<br>
><br>
> current lack of standardization aside, there is another pretty fundamental<br>
> security related issue here, that we probably need to make a conscious<br>
> decision about.<br>
><br>
> Those kind of API are usually associated to the web browser's web<br>
> application frameworks, often requiring certain permissions. Thus the<br>
> application launcher (and installer) are implemented in the browser itself,<br>
> not in the content. So to get a Sugar like launcher (and "window" manager)<br>
> you would need to patch or customize the web browser. That makes it harder<br>
> to run Sugar, you need to install an application rather just going to a<br>
> website, and I'm not too convinced we have resources to develop it anyway.<br>
><br>
> Another possibility for us would be to this kind of stuff server side, at<br>
> least when it's not hardware related (settings, journal etc). That doesn't<br>
> make the security issue go away, but maybe there are ways we can provide<br>
> that security through the normal client/server interaction.<br>
><br>
> The situation of the various Sugars we have been discussing is pretty<br>
> different in this regard<br>
><br>
> * Sugar on Linux. We actually control the launcher there, though WebKit<br>
> doesn't have a web application framework we can use. When these API will<br>
> standardized I suppose we could hope generic support for one will be added.<br>
> For now, one has been implemented in Chrome, so on an higher layer that we<br>
> can't use.<br>
> * Sugar on Android. If we wanted I guess we could add support for these an<br>
> API in the native wrapper. The implementation would be on us though.<br>
> * Sugar on a Web site. Well, there is no web application launcher by<br>
> definition there.<br>
><br>
> My feeling is that the most pragmatic approach would be to implement<br>
> settings, datastore and similar APIs on the server. We can either use the<br>
> current websocket protocol or implement something more web friendly as it as<br>
> been suggested (for example http POST to store files). On Linux we can run<br>
> the server locally. Sugar on Android is just a wrapper loading Sugar on a<br>
> Web site from the remote server.<br>
><br>
> That said I don't think there is a perfect solution given our resources and<br>
> honestly I'm not really sure which of the realistic options is the best one.<br>
<br>
</div></div>Absolutely. I don't have the answer too.<br>
<br>
In the long term, I think we should keep an eye at mozilla's WebAPI.<br>
They are the ones doing a complete web OS. But for a current,<br>
realistic approach, I agree that a server might suffice for the non<br>
hardware settings.<br>
<span><font color="#888888"><br>
--<br>
.. manuq ..<br>
</font></span></blockquote></div><br></div>
</blockquote></div><br><br></div></div><span class="HOEnZb"><font color="#888888">-- <br>Daniel Narvaez<br><br>
</font></span><br>_______________________________________________<br>
Sugar-devel mailing list<br>
<a href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a><br>
<a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br>
<br></blockquote></div><br></div>