[Sugar-devel] Oversight Board request: Not fully bundled .xo

[Aleksey Lim]

Hi all,


This is request to Oversight Board because of:

* Activity bundles (.xo files) are one of sugar cornerstones
  positive answer to this question will affect general sugar workflows
  (see background notes for examples).

* Sugar upstream (Sugar Labs) should be more friendly to existed, not
  sugar based, education software to provide sugar killing features for
  these projects instead of reimplementing education stack in sugar.
  And activity bundles are obvious tools for that but existed .xo
  format does not work well here.

* The main Sugar Labs (thus downstream agnostic) deployment instrument -
  Activity Library [1] is getting to be messy when more than a half of
  activities are binaries, it is a real problem since SL is not
  GNU/Linux distribution vendor and more over should be distribution
  agnostic and .xo are not intended to handle binaries properly.

* The matter of this request is not technical details (will be discussed
  in more regular ways) but declaring principal changing in sugar
  workflow.

* Things like poll is not so popular [3] and it is pretty unfair to make 
  critical decisions basing on 14 votes.


Request:

  Can activity bundles on Activity Library [1] be not fully bundled
  and demand additional (except having .xo) steps (that in most cases
  will demand network connection) to its launch.


Possible implementation details (is not a part of request, just info):

* Using 0sugar [4] infrastructure to handle non Sugar Platform [2]
  dependencies. 0sugar is an infrastructure wrapper around 0install [5].

* Fully bundled .xo could be preserved (it makes sense for pure network
  environments), not fully bundled activities could be in form of web
  urls for example [6] in that case they will obviously separated from
  regular .xo.

* Activity Library [1] could provide two download buttons, one (main)
  for regular fully bundled .xo and second for lightweight activities.

* Binary dependencies (if there is no way to install from native
  packaging systems) will be built on public building farm thus we can
  guarantee that they will be built properly and will keep activity
  developers out of such not trivial stuff.


Background:

  .xo idea of being fully bundled is pretty useful on its own and works
  fine in case of pure python activities.
  
  But I'm sure SL's purposes is not creating python based education
  platform thus it is more useful way to treat sugar as an education
  environment which provides useful features for the rest of education
  software instead of creating education platform from scratch in pure
  python. Distribution agnostic deployment portal - ASLO, would be
  another killing future of sugar when all education software that
  support sugar platform could be installed from one place. From that
  point fully bundled .xo don't work because bundling Java or Qt is
  pretty useless.

  Fully bundled .xo could still work in case of one deploying scheme
  e.g. OLPC - there is only one hardware platform and only one software
  platform with release cycle more then a year (2?). Another successful
  example is MacOS which is also only one software platform with long
  releasing cycle. But SL's case if different since it is trying to be
  GNU/Linux distribution agnostic and fully bundled binaries don't play
  here. Thus GNU/Linux distribution efforts should be used as much as
  possible when proper dependency will be installed from native packages
  and fallback for homemade binaries in extreme cases.


[1] http://activities.sugarlabs.org/
[2] http://wiki.sugarlabs.org/go/0.88/Platform_Components
[3] http://idea.olpcorps.net/drupal5/ideatorrent/idea/20/
[4] http://wiki.sugarlabs.org/go/Activity_Team/Services
[5] http://0install.net/goals.html
[6] http://wiki.sugarlabs.org/go/Features/Zero_Sugar_Activities

-- 
Aleksey