[Sugar-devel] Fwd: Sugar-devel Digest, Vol 64, Issue 36

[Manuel Quiñones]

Forwarding a message from Tony Anderson, because he can't send to the
mailing list.


---------- Forwarded message ----------
From: Tony Anderson <tony at olenepal.org>
Date: 2014-02-17 21:40 GMT-03:00
Subject: Re: Sugar-devel Digest, Vol 64, Issue 36
To: manuq at laptop.org


Hi,

Unfortunately my current internet provider doesn't accept mail sent
with my regular email address and so I cannot reply to the list.

I am trying to implement a backup/restore system that will work with
current builds (13 and 21). The environment to be supported is a set
of XOs with a sometimes LAN connection to a schoolserver. Further, the
set of XOs are shared with multiple users (e.g. grade 1 at 8am, grade
2 at 10am, and so on.

The design assumes that there is not enough extra funds to purchase
USB sticks and that SOAS is inappropriate because the only computers
available to the site are the laptops and server. The design does not
take into account the web developments underway.

The approach is to make the changes to the Journal activity. The site
must supply a roster of students and staff (essentially anyone whose
work will be saved). This takes the form of a csv file which can be
created from a spreadsheet (e.g. socialcalc). At boot, the user is
requested to login. The user clicks on the grade (or role). This
provides a list of the names. The user clicks on their name to
complete login. This approach avoids the need for very young children
to have to enter a name and password on a keyboard. One role is guest.
In this role, the user has access to the capabilities of the system
but no work will be saved.

The volumes toolbar shows the login status. Login updates the computer
nick so that collaboration will reflect the actual user. One current
problem is that changes to the nick in gconf are not effective until
the system is restarted. Hopefully, it will be possible to set up a
signal on nick change.

At login, the datamanager procedure is run. If the laptop is connected
to the school server, the Journal is backed up. The datamanager (using
the datastore class) reads all of the datastore. If a Journal object
has been saved, the fact is recorded in the object's metadata. If a
new item, the datamanager checks whether the object includes a data
file. If so the journal object and file are uploaded to the
schoolserver by the serial-number as currently. The object is stored
as two files in the journal folder in the /library/users/serial-number
folder. If the object has no data file, the metadata is uploaded to
the log file in /llibrary/users/serial-number/log file. The object is
deleted from the local datastore.

The datamanager, when connected to the school server, checks space
available. Quotas are set based on the XO model (e.g XO-1 is tighter
than XO-1+). There need to be quotas for datastore size and the size
of the Activities folder. There may be needs to manage other 'growth'
such as Gnome or the web persistent store. In the case of the Journal,
guest objects are deleted. Data files for Journal objects for users
not logged in are deleted LRU as needed. For Sugar activities, they
are deleted LRU.  This policy needs review since at sites where
laptops are rotated through a set of students, this could lead to
'thrashing'.

An additional favorite button (probably a circle) is added to the
Journal display for each object. If there is a local copy of the file
- the circle has the XO color. Otherwise, it is transparent. The user
can click on this button to set or clear. if it is clear and the user
sets it and the laptop is connected to schoolserver, the file is
downloaded. If the button is clear, the corresponding data file is
deleted (but still available from the school server).

The Journal activity only displays Journal objects 'owned' by the
logged in user. If the user logs in from a different laptop and is
connected to the school server, the datamanager downloads the metadata
for the user's journal objects.

If the user logs in from home (i.e. not connected to the school
server), the list of users is maintain locally on the XO to enable new
journal objects to be associated with the owner. The Journal activity
will show only local Journal objects owned by that user - possibly
none.

A server side procedure run as a cron job reads all the journal
objects for all serial-numbers and adds a corresponding entry to a
Django database. This database is used to retrieve the metadata for a
user logging in. The path to files associated with a Journal object
are recorded in the database.

The activities.py is modified to record the current value of the nick
as the 'owner' of a new Journal object. Note: the nick is actually
three entries in gconf: nick, id, and role(grade). The id is the
database primary key which can be a site supplied registration number
(learner reference number) or the Django PK. This means that
information obtained from the school server users folders can be used
without revealing personal information (only available from the
database).

In addition, activities.py is modified to record in the Journal object
metadata the id, launch time, stop time, and outcome of the activity.
By default, the outcome is an empty string. However, activities can
use a write_outcome procedure (like write_file) to record an outcome
as a string. The string, of course, can be an arbitrary JSON. This
provides the possibility for teachers to have activities such as
quizzes which report the student's actual results.

The current status is that I have snippets of code for most of the
features - but the system is far from deployable. I am working to have
it ready for the Paris meeting in April.

Yours,

Tony
On 02/18/2014 03:43 AM, sugar-devel-request at lists.sugarlabs.org wrote:
>
> Message: 4
> Date: Mon, 17 Feb 2014 16:35:27 -0300
> From: Manuel Qui?ones<manuq at laptop.org>
> To: Sugar-dev Devel<sugar-devel at lists.sugarlabs.org>
> Subject: [Sugar-devel] [DESIGN] Backup / Restore feature
> Message-ID:
>         <CAPpV+Obruc42AYPQQznKnHjwBwmCWj=fKgBpFvh9F9mhCo4nDA at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Sending my comment to the mailing list to open discussion.
> Feature pages:
> -http://wiki.sugarlabs.org/go/Features/Backup_and_Restore
> -http://wiki.sugarlabs.org/go/Features/Backup_and_Restore/Enhancements
>
> Pull request
> -https://github.com/sugarlabs/sugar/pull/176
>
>
> I think this feature should live in My Settings for the following reasons:
>
> - it is a global operation, like My Settings > Software Update
>
> - the patch adds a new modal window that is very similar to My
> Settings.  This is very prone to confusion. And we should aim to have
> only one modal to not complicate the shell.
>
> - the code should live in extensions/cpsection.  This way is more
> separated from the shell.  The less shell code we maintain, the
> better.  And the less decoupled from the Journal, the better too (I
> had to solve one conflict to test it already).
>
> i can see why is good to have this attached to the Journal, but in my
> opinion there are more cons than pros going that way.
>
> Design feedback
>
> - make the background white like any other CP section
> - the buttons should not have a border, they should be similar to the
> ones in CP sectino
> - the buttons should not enlarge to fit the available space
> - the icons in buttons are too big, they should be the same size as CP
> section icons (GRID_CELL_SIZE)
> - the icons should have black stroke, white fill
> - the combo box should not enlarge too, use a left-aligned layout,
> like others CP sections
> - the progress dialog should be similar than the Software Update progress
> - Journal should be written with capital letter
>
> Testing
>
> - "remote backup" did nothing in my Sugar after pressing Continue.
> When is this option valid?  Can this option be avoided in that case?
>
> References
>
> - Sofrware Update progress
> https://f.cloud.github.com/assets/83944/2188629/176e3154-9809-11e3-8aad-48afa77743dc.png
>
> - Combos are too wide:
> https://f.cloud.github.com/assets/83944/2188634/2d55f1b4-9809-11e3-85a0-e76286357e91.png
>
> - Icons too big:
> https://f.cloud.github.com/assets/83944/2188641/47ec1d5a-9809-11e3-9ae9-ec8a119f84eb.png
>
> - Suggested style for buttons:
> https://f.cloud.github.com/assets/83944/2188681/fad198c8-9809-11e3-9f47-5e836c26844a.png
>
> -- .. manuq ..




-- 
.. manuq ..