<div dir="ltr">This is another feature, and a big change by itself.<div>Looks like a solution to the problem of "one xo, may children".</div><div>I wonder if something like this can be implemented with the "remote journal"</div>
<div>and the webservices backend like tincho shared a few weeks ago.</div><div><br></div><div>Gonzalo</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 18, 2014 at 9:23 AM, Manuel Quiñones <span dir="ltr"><<a href="mailto:manuq@laptop.org" target="_blank">manuq@laptop.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Forwarding a message from Tony Anderson, because he can't send to the<br>
mailing list.<br>
<br>
<br>
---------- Forwarded message ----------<br>
From: Tony Anderson <<a href="mailto:tony@olenepal.org">tony@olenepal.org</a>><br>
Date: 2014-02-17 21:40 GMT-03:00<br>
Subject: Re: Sugar-devel Digest, Vol 64, Issue 36<br>
To: <a href="mailto:manuq@laptop.org">manuq@laptop.org</a><br>
<br>
<br>
Hi,<br>
<br>
Unfortunately my current internet provider doesn't accept mail sent<br>
with my regular email address and so I cannot reply to the list.<br>
<br>
I am trying to implement a backup/restore system that will work with<br>
current builds (13 and 21). The environment to be supported is a set<br>
of XOs with a sometimes LAN connection to a schoolserver. Further, the<br>
set of XOs are shared with multiple users (e.g. grade 1 at 8am, grade<br>
2 at 10am, and so on.<br>
<br>
The design assumes that there is not enough extra funds to purchase<br>
USB sticks and that SOAS is inappropriate because the only computers<br>
available to the site are the laptops and server. The design does not<br>
take into account the web developments underway.<br>
<br>
The approach is to make the changes to the Journal activity. The site<br>
must supply a roster of students and staff (essentially anyone whose<br>
work will be saved). This takes the form of a csv file which can be<br>
created from a spreadsheet (e.g. socialcalc). At boot, the user is<br>
requested to login. The user clicks on the grade (or role). This<br>
provides a list of the names. The user clicks on their name to<br>
complete login. This approach avoids the need for very young children<br>
to have to enter a name and password on a keyboard. One role is guest.<br>
In this role, the user has access to the capabilities of the system<br>
but no work will be saved.<br>
<br>
The volumes toolbar shows the login status. Login updates the computer<br>
nick so that collaboration will reflect the actual user. One current<br>
problem is that changes to the nick in gconf are not effective until<br>
the system is restarted. Hopefully, it will be possible to set up a<br>
signal on nick change.<br>
<br>
At login, the datamanager procedure is run. If the laptop is connected<br>
to the school server, the Journal is backed up. The datamanager (using<br>
the datastore class) reads all of the datastore. If a Journal object<br>
has been saved, the fact is recorded in the object's metadata. If a<br>
new item, the datamanager checks whether the object includes a data<br>
file. If so the journal object and file are uploaded to the<br>
schoolserver by the serial-number as currently. The object is stored<br>
as two files in the journal folder in the /library/users/serial-number<br>
folder. If the object has no data file, the metadata is uploaded to<br>
the log file in /llibrary/users/serial-number/log file. The object is<br>
deleted from the local datastore.<br>
<br>
The datamanager, when connected to the school server, checks space<br>
available. Quotas are set based on the XO model (e.g XO-1 is tighter<br>
than XO-1+). There need to be quotas for datastore size and the size<br>
of the Activities folder. There may be needs to manage other 'growth'<br>
such as Gnome or the web persistent store. In the case of the Journal,<br>
guest objects are deleted. Data files for Journal objects for users<br>
not logged in are deleted LRU as needed. For Sugar activities, they<br>
are deleted LRU.  This policy needs review since at sites where<br>
laptops are rotated through a set of students, this could lead to<br>
'thrashing'.<br>
<br>
An additional favorite button (probably a circle) is added to the<br>
Journal display for each object. If there is a local copy of the file<br>
- the circle has the XO color. Otherwise, it is transparent. The user<br>
can click on this button to set or clear. if it is clear and the user<br>
sets it and the laptop is connected to schoolserver, the file is<br>
downloaded. If the button is clear, the corresponding data file is<br>
deleted (but still available from the school server).<br>
<br>
The Journal activity only displays Journal objects 'owned' by the<br>
logged in user. If the user logs in from a different laptop and is<br>
connected to the school server, the datamanager downloads the metadata<br>
for the user's journal objects.<br>
<br>
If the user logs in from home (i.e. not connected to the school<br>
server), the list of users is maintain locally on the XO to enable new<br>
journal objects to be associated with the owner. The Journal activity<br>
will show only local Journal objects owned by that user - possibly<br>
none.<br>
<br>
A server side procedure run as a cron job reads all the journal<br>
objects for all serial-numbers and adds a corresponding entry to a<br>
Django database. This database is used to retrieve the metadata for a<br>
user logging in. The path to files associated with a Journal object<br>
are recorded in the database.<br>
<br>
The activities.py is modified to record the current value of the nick<br>
as the 'owner' of a new Journal object. Note: the nick is actually<br>
three entries in gconf: nick, id, and role(grade). The id is the<br>
database primary key which can be a site supplied registration number<br>
(learner reference number) or the Django PK. This means that<br>
information obtained from the school server users folders can be used<br>
without revealing personal information (only available from the<br>
database).<br>
<br>
In addition, activities.py is modified to record in the Journal object<br>
metadata the id, launch time, stop time, and outcome of the activity.<br>
By default, the outcome is an empty string. However, activities can<br>
use a write_outcome procedure (like write_file) to record an outcome<br>
as a string. The string, of course, can be an arbitrary JSON. This<br>
provides the possibility for teachers to have activities such as<br>
quizzes which report the student's actual results.<br>
<br>
The current status is that I have snippets of code for most of the<br>
features - but the system is far from deployable. I am working to have<br>
it ready for the Paris meeting in April.<br>
<br>
Yours,<br>
<br>
Tony<br>
On 02/18/2014 03:43 AM, <a href="mailto:sugar-devel-request@lists.sugarlabs.org">sugar-devel-request@lists.sugarlabs.org</a> wrote:<br>
><br>
> Message: 4<br>
> Date: Mon, 17 Feb 2014 16:35:27 -0300<br>
> From: Manuel Qui?ones<<a href="mailto:manuq@laptop.org">manuq@laptop.org</a>><br>
> To: Sugar-dev Devel<<a href="mailto:sugar-devel@lists.sugarlabs.org">sugar-devel@lists.sugarlabs.org</a>><br>
> Subject: [Sugar-devel] [DESIGN] Backup / Restore feature<br>
> Message-ID:<br>
>         <CAPpV+Obruc42AYPQQznKnHjwBwmCWj=<a href="mailto:fKgBpFvh9F9mhCo4nDA@mail.gmail.com">fKgBpFvh9F9mhCo4nDA@mail.gmail.com</a>><br>
> Content-Type: text/plain; charset=UTF-8<br>
><br>
> Sending my comment to the mailing list to open discussion.<br>
> Feature pages:<br>
> -<a href="http://wiki.sugarlabs.org/go/Features/Backup_and_Restore" target="_blank">http://wiki.sugarlabs.org/go/Features/Backup_and_Restore</a><br>
> -<a href="http://wiki.sugarlabs.org/go/Features/Backup_and_Restore/Enhancements" target="_blank">http://wiki.sugarlabs.org/go/Features/Backup_and_Restore/Enhancements</a><br>
><br>
> Pull request<br>
> -<a href="https://github.com/sugarlabs/sugar/pull/176" target="_blank">https://github.com/sugarlabs/sugar/pull/176</a><br>
><br>
><br>
> I think this feature should live in My Settings for the following reasons:<br>
><br>
> - it is a global operation, like My Settings > Software Update<br>
><br>
> - the patch adds a new modal window that is very similar to My<br>
> Settings.  This is very prone to confusion. And we should aim to have<br>
> only one modal to not complicate the shell.<br>
><br>
> - the code should live in extensions/cpsection.  This way is more<br>
> separated from the shell.  The less shell code we maintain, the<br>
> better.  And the less decoupled from the Journal, the better too (I<br>
> had to solve one conflict to test it already).<br>
><br>
> i can see why is good to have this attached to the Journal, but in my<br>
> opinion there are more cons than pros going that way.<br>
><br>
> Design feedback<br>
><br>
> - make the background white like any other CP section<br>
> - the buttons should not have a border, they should be similar to the<br>
> ones in CP sectino<br>
> - the buttons should not enlarge to fit the available space<br>
> - the icons in buttons are too big, they should be the same size as CP<br>
> section icons (GRID_CELL_SIZE)<br>
> - the icons should have black stroke, white fill<br>
> - the combo box should not enlarge too, use a left-aligned layout,<br>
> like others CP sections<br>
> - the progress dialog should be similar than the Software Update progress<br>
> - Journal should be written with capital letter<br>
><br>
> Testing<br>
><br>
> - "remote backup" did nothing in my Sugar after pressing Continue.<br>
> When is this option valid?  Can this option be avoided in that case?<br>
><br>
> References<br>
><br>
> - Sofrware Update progress<br>
> <a href="https://f.cloud.github.com/assets/83944/2188629/176e3154-9809-11e3-8aad-48afa77743dc.png" target="_blank">https://f.cloud.github.com/assets/83944/2188629/176e3154-9809-11e3-8aad-48afa77743dc.png</a><br>
><br>
> - Combos are too wide:<br>
> <a href="https://f.cloud.github.com/assets/83944/2188634/2d55f1b4-9809-11e3-85a0-e76286357e91.png" target="_blank">https://f.cloud.github.com/assets/83944/2188634/2d55f1b4-9809-11e3-85a0-e76286357e91.png</a><br>
><br>
> - Icons too big:<br>
> <a href="https://f.cloud.github.com/assets/83944/2188641/47ec1d5a-9809-11e3-9ae9-ec8a119f84eb.png" target="_blank">https://f.cloud.github.com/assets/83944/2188641/47ec1d5a-9809-11e3-9ae9-ec8a119f84eb.png</a><br>
><br>
> - Suggested style for buttons:<br>
> <a href="https://f.cloud.github.com/assets/83944/2188681/fad198c8-9809-11e3-9f47-5e836c26844a.png" target="_blank">https://f.cloud.github.com/assets/83944/2188681/fad198c8-9809-11e3-9f47-5e836c26844a.png</a><br>
><br>
> -- .. manuq ..<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
<br>
--<br>
.. manuq ..<br>
_______________________________________________<br>
Sugar-devel mailing list<br>
<a href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a><br>
<a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Gonzalo Odiard<br><br><div>SugarLabs - Learning Software for children<br></div></div>
</div>