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

[Gonzalo Odiard]

This is another feature, and a big change by itself.
Looks like a solution to the problem of "one xo, may children".
I wonder if something like this can be implemented with the "remote journal"
and the webservices backend like tincho shared a few weeks ago.

Gonzalo


On Tue, Feb 18, 2014 at 9:23 AM, Manuel Quiñones <manuq at laptop.org> wrote:

> 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 ..
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
Gonzalo Odiard

SugarLabs - Learning Software for children
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20140218/b8ab59dd/attachment-0001.html>