[Sugar-devel] How to deploy the webactivity libraries

[Daniel Drake]

Thanks for starting this thread - it is something that needs to be
carefully discussed and considered.
Just one comment to add for now:

On Wed, May 29, 2013 at 4:29 AM, Simon Schampijer <simon at schampijer.de> wrote:
> ===Include a copy of the library in each webactivity===
> Each activity carries a copy of the libraries it uses. For example
> sugar-html-activity and sugar-html-graphics. This has the advantage that the
> activities are self contained. The downside is that for a change in the
> library each activity has to be updated.

I would imagine that that making the assumption that we can have "self
contained" activities is dangerous. By this, I infer that we envision
the possibility (perhaps in addition to other possibilities) that an
activity can be bundled up and run on any version of HTML-enabled
Sugar, older or newer than the one it was developed against. While it
may work in some cases, I am not convinced that this is truly
achievable.

While the web browser environment works as a self-contained virtual
machine for many, many things, once we get adventurous I think it is
inevitable that activities will start depending on specific, new
features of the underlying web browser, and/or specific features/API
implemented by the underlying Sugar shell, and/or specific
features/API of the underlying operating system.

For example, I'll invent a situation that I am not sure is true or
not, but would reflect something that seems perfectly realistic and
could bite in a number of cases: Our initial stable "Sugar HTML"
release doesn't support webcam use, because there is no API or
anything that activities can use to access the webcam. A couple of
releases later, time has passed and HTML5 expands to include a brand
new <webcam> tag, which activities start to use as it becomes
supported in the brand new webkit version that appears in Fedora. An
activity starts to use this. It bundles all the stuff it can, but it
is *not* truly self contained. It will not work on older platform
releases because it relies on a specific new feature in the web engine
- and the web engine is part of the system, it is not something
bundled in the activity.

An alternative situation: instead of such funtionality being added to
HTML5, we add functionality to the underlying Sugar shell which
somehow provides some access to V4L2 devices (i.e. webcams) from
javascript, for use by activities. Activities can start using that and
bundle loads of stuff, but they will not be truly self contained
because at some point they will have a dependency on something
system-specific which will not work on older releases of the platform.

In other words, I imagine that for activities that meet a certain
level of complexity/functionality, there will commonly be some point
at which they cross the line and start depending something specific in
the underlying system, which breaks any dreams of self contained
activities. If I'm right, maybe we should consider dropping that as a
realistic possibility for a reliable experience.

Daniel