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

[Manuel Quiñones]

Hi Daniel,

2013/11/14 Daniel Narvaez <dwnarvaez at gmail.com>:
> 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.

Mozilla solution for system settings:
https://developer.mozilla.org/en-US/docs/WebAPI/Settings

Is not part of any web specification, but is in the roadmap of this W3C group:
http://www.w3.org/2012/sysapps/ - System Applications Working Group

>
> 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é <lionel at olpc-france.org> 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] https://build.phonegap.com/
>>
>> [2] https://github.com/llaske/SugarWebUI
>>
>> [3]
>> https://github.com/llaske/SugarWebUI/blob/master/lib/sugar-web/bus.js#L150
>>
>> [4] https://github.com/llaske/SugarWebUI/blob/master/js/settings.js#L5
>>
>> [5] https://github.com/llaske/SugarWebUI/blob/master/js/settings.js#L65
>>
>> [6]
>> https://github.com/llaske/SugarWebUI/blob/master/lib/sugar-web/bus.js#L168
>>
>>
>>
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>
>
>
> --
> Daniel Narvaez
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
.. manuq ..