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 <dwnarv...@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 <ma...@laptop.org> >> >>> 2013/11/14 Daniel Narvaez <dwnarv...@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@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > >
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel