[Sugar-devel] [IAEP] (Goals and Mission) with Microsoft in it?

[Tony Anderson]

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

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.

Tony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20170518/0ef706f9/attachment.html>