<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 05/17/2017 11:07 PM, Samuel Cantero
wrote:<br>
</div>
<blockquote
cite="mid:CAGA8R4mnzP=aiEsfRze9sAe_GGSiqjSm9C=8LOpBH228CHKt=A@mail.gmail.com"
type="cite">
<div class="moz-text-html" lang="x-unicode">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>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 (<i>microformat</i>) is the way I'll
go.</div>
<div><br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
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. <br>
<br>
<blockquote
cite="mid:CAGA8R4mnzP=aiEsfRze9sAe_GGSiqjSm9C=8LOpBH228CHKt=A@mail.gmail.com"
type="cite">
<div class="moz-text-html" lang="x-unicode">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>
<div>So, at first stage, I propose to add only <i>microformat</i>
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.</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
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. <br>
<br>
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).<br>
<br>
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. <br>
<br>
Tony<br>
</body>
</html>