[Sugar-devel] [IAEP] (Goals and Mission) with Microsoft in it?
tony_anderson at usa.net
Wed May 17 21:02:17 EDT 2017
On 05/17/2017 11:07 PM, Samuel Cantero wrote:
> AFAIK not all deployments are using ASLO as main backend for Software
> Update. In fact, an static "update URL" with activity information in
> semantic microformat seems more reliable. In my case, I will never
> allow and trust in last version sent by a developer in ASLO. Updating
> ~13K XOs w/o testing the activities first doesn't look reasonable for
> me. So testing in your own environment and updating the activity
> information in the the activity page (/microformat/) is the way I'll go.
My model is that deployments start by reflashing a Sugar image (e.g.
0.110) - before the start of the new academic year. Most deployments do
not want to modify that installation during the year to maintain
consistent behavior. The deployment can delete or add activities after
the flash to meet its needs.
> So, at first stage, I propose to add only /microformat/ support for
> ASLOv3. A person (image builder..) who is building an image must be
> able to select a set of activity/version pair and generate the 'update
> URL' in semantic microformat. This person must be able to update the
> content at any time keeping the same "update URL". This will allow us
> to use Sugar Software Update functionality.
Assuming the workings of the Sugar Software Update are unaffected, I
don't think this functionality is needed for activities. If a new
version of an activity is released and the deployment wants to implement
it immediately, they only need to advise the learners to erase the
current version by list view and to download the new version from the
I assume when you refer to 13K XOs, these are not all in a single room
but distributed across a number of deployments as in Rwanda. In Rwanda
schools range from 400 with the mode around 200. Currently reflash is
done by usb stick. After the reflash, the configuration of activities is
updated to meet the deployment needs. During the school year, no changes
are made (except to reflash except when needed for repair or replacement
of the XO).
For this, I would like to see a network install à la nandblaster. In
Rwanda this would also have to update the activation lease. In Rwanda, I
experimented with one-off activities to perform updates, which works
well. Basically modify helloword-6.xo to update-1.xo where update has a
script (subprocess + command line) which makes the needed change. This
minimizes the 'learning curve' for the user. They download the activity
from the school server, run it once, and erase it. Such an activity can
be made in a matter of moments and can be distributed by school server
or by usb stick. It can also be distributed by SimpleHTTPServer through
the ad hoc network.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Sugar-devel