<div dir="ltr"><div><div><div>Hi Manuel, </div>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. </div>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. </div><div>The situation of the various Sugars we have been discussing is pretty different in this regard </div><div>* 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. </div><div>* 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. </div><div>* Sugar on a Web site. Well, there is no web application launcher by definition there. </div><div>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. </div><div>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. </div><div> </div></div><div class="gmail_extra"> <div class="gmail_quote">On 14 November 2013 13:21, Manuel Quiñones <<a href="mailto:manuq@laptop.org" target="_blank">manuq@laptop.org</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Hi Daniel, 2013/11/14 Daniel Narvaez <<a href="mailto:dwnarvaez@gmail.com">dwnarvaez@gmail.com</a>>: <div class="im">> I think there is a pretty fundamental issue we need to figure out, the > solution to several of the issues you pointed out depends on this. > > Should activities be each a separate web application or should all the part > of the Sugar web application? Or more technically, should they have the same > origin or each a different one? > > That has major consequences. For example a different origin gives each a > separate LocalStorage, which is great for security and namespacing but > makes, for example, communicating the xo color more complicated. A lot of > others standard web APIs are affected by the origin. </div>Mozilla solution for system settings: <a href="https://developer.mozilla.org/en-US/docs/WebAPI/Settings" target="_blank">https://developer.mozilla.org/en-US/docs/WebAPI/Settings</a> Is not part of any web specification, but is in the roadmap of this W3C group: <a href="http://www.w3.org/2012/sysapps/" target="_blank">http://www.w3.org/2012/sysapps/</a> - System Applications Working Group <div><div class="h5"> > > Security aside, this also affects how activities are "deployed". Do we want > to be able to run activities from a different web server or must everything > come from the same? If we want different web servers than I guess we are > sort of forced into multiple origins (though you could still download a > bundle from a different server and install on the main one). > > For what it's worth in Sugar 0.100 each web activity has a different origin. > > > On 14 November 2013 10:03, Lionel Laské <<a href="mailto:lionel@olpc-france.org">lionel@olpc-france.org</a>> wrote: >> >> >> Hi all, >> >> >> >> Thanks a lot for your messages regarding my work. Very appreciate to see >> enthusiasm here. >> >> I'm opening a different thread to talk about technical issues. >> >> >> >> Technically speaking my prototype is three things: >> >> A Sugar Web Activities that mimic the desktop. This "activity" use the >> Sugar Web Framework (toolbar, xocolor, …) and is written using Enyo >> Framework (not the better JavaScript framework but it's my favorite one :-). >> The framework is "dynamic" so adding new activities is very easy (see here >> [4]). In fact, I hope to integrate a mechanism to install new activity from >> the desktop. >> A directory name "activities" where I've unzip the content of .XO files >> for all web activities currently on Sugar App Store. The desktop activity >> just switch from an activity to another [5]. >> A PhoneGap encapsulation that allow to generate the Android APK. BTW >> because I'm using PhoneGap Build [1], it will also generate other platforms >> (iOS, webOS, …). >> >> >> >> Here are the major issues I've faced building the prototype (all source >> code is here [2]): >> >> >> >> Multiple copy of Sugar Framework in each activity. My work was mostly a >> way to group existing Sugar Web activities. BTW I need to upgrade a part of >> the Sugar Web Framework to implement few features (Stop button, XO Colors, >> …). This upgrade concern today the bus.js file (most of the hack is here >> [3]) but this file is copied in each web activities :-( So I had to upgrade >> this file in each activity directory. I think we must find a way to allow >> the Sugar Web Framework to be deployed/referenced one time only. >> Server side stuff. Today the Sugar Web Framework use Web Sockets to >> communicate with the system layer. It's good when running on Sugar but it's >> not a good idea in a Web-Browser only world because you can't have a process >> to listen Web Sockets. I think we should imagine a way to have a Sugar Web >> Framework that could work in stand-alone mode (without any server side). For >> example by using directly LocalStorage instead of waiting for a bus call. >> It's what I've done to retrieve xocolor [6] >> HTML5 compatibility issues. Running existing Sugar Web Activities on >> tablets (XO Tablet and Samsung GalaxyTab) raise some issues regarding HTML5 >> compatibility. Specifically some features (CustomEvent object, Blob object, >> window.webkitRequestAnimationFrame, …) used by the framework or by >> activities don't work everywhere due to WebKit compatibility. I think we >> should isolate these features (or avoid using it). Of course one another >> major issue is that the screen size could be very different from a device to >> another. Unfortunately activities are often linked to the XO screen size. >> Environment. The Sugar Web Framework use an environment object (env.js), >> it seems to be used to detect the current platform but that I don't >> understand exactly how it works. Any explication regarding this point will >> be appreciate. >> >> >> >> Hope to have your proposal or feedbacks. >> >> Do not hesitate to ask me for more. >> >> >> >> Lionel. >> >> >> >> >> >> [1] <a href="https://build.phonegap.com/" target="_blank">https://build.phonegap.com/</a> >> >> [2] <a href="https://github.com/llaske/SugarWebUI" target="_blank">https://github.com/llaske/SugarWebUI</a> >> >> [3] >> <a href="https://github.com/llaske/SugarWebUI/blob/master/lib/sugar-web/bus.js#L150" target="_blank">https://github.com/llaske/SugarWebUI/blob/master/lib/sugar-web/bus.js#L150</a> >> >> [4] <a href="https://github.com/llaske/SugarWebUI/blob/master/js/settings.js#L5" target="_blank">https://github.com/llaske/SugarWebUI/blob/master/js/settings.js#L5</a> >> >> [5] <a href="https://github.com/llaske/SugarWebUI/blob/master/js/settings.js#L65" target="_blank">https://github.com/llaske/SugarWebUI/blob/master/js/settings.js#L65</a> >> >> [6] >> <a href="https://github.com/llaske/SugarWebUI/blob/master/lib/sugar-web/bus.js#L168" target="_blank">https://github.com/llaske/SugarWebUI/blob/master/lib/sugar-web/bus.js#L168</a> >> >> >> >> _______________________________________________ >> Sugar-devel mailing list >> <a href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a> >> <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a> >> > > > > -- > Daniel Narvaez > > _______________________________________________ > Sugar-devel mailing list > <a href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a> > <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a> > -- </div></div>.. manuq .. </blockquote></div> -- Daniel Narvaez </div>