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

[Daniel Narvaez]

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.



On 14 November 2013 13:21, Manuel Quiñones <manuq at laptop.org> wrote:

> 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 ..
>



-- 
Daniel Narvaez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20131114/532b7829/attachment.html>