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

[Daniel Narvaez]

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20131114/2c4e835b/attachment.html>