Re: DataManager version 1
Wade, The format of the datastore changed after 0.82. I tried to caution users on that. The .sugar/default/datastore/store is the location in 0.82. All of the DataManager actions should be done through the datastore class but there were some things I couldn't get to work. I am hoping that we can get a chance to check this out in a real environment in Nepal in the next few weeks (I should be there on 30 September). In the longer run, we also need to reconcile the backup in DataManager with Martin's strategy in the schoolserver. At the moment, the two are independent (and therefore duplicate). Yours, Tony Wade Brainerd wrote: Hi Tony, This sounds like a great approach to managing backup. I particularly like the color coding scheme and the way the user gets control over the process. I wonder if this feature should be integrated into the Journal itself somehow, or pehaps made into a control panel applet? It seems like doing the work when you hit 'Stop' is inconsistent with the way other activities function. A control panel applet would also get better privileges by default. I tried to launch DataManager as downloaded from ASLO but it hit an exception. Attached is a patch which lets it get further through startup, but it still fails looking for ~/.sugar/default/datastore/store. I'm not familiar with the format of the datastore, or how it has changed in recent Sugar versions. Looking forward to seeing how this progresses. Let us know how it does in Nepal! Regards, Wade On Fri, Aug 28, 2009 at 1:38 PM, Tony Anderson t...@olenepal.org mailto:t...@olenepal.org wrote: Hi, I posted the DataManager activity to ASLO today. It matches the code currently on gitorious. The intent of the DataManager is to deal with a problem faced in Nepal which is the small size of the Nand. The current backup/restore feature does not provide a way for the user to remove entries from the local store. The activity works on 0.82 with the Nepal version of the schoolserver, although I don't see why it wouldn't work with any version. It works in three phases. At launch it builds a list from the schoolserver (when connected) of all the entries. It provides a color code: light green - entry not stored locally green - entry stored locally (as well as on the schoolserver) cyan - entry on the schoolserver in Commons blue - entry from Commons stored locally red - new entry not yet uploaded to the schoolserver white - entry without an associated document The status bar reports the number of entries in the datastore and the percentage of the Nand in use. In phase 2 the user can double-click on an entry. If it is on the local XO (green or blue), it will be removed (but will still be on the schoolserver). If it is not on the XO (light green or cyan), it will be downloaded to the XO. When the user clicks on the Stop button on the activity toolbar, the activity performs the file operations: upload, download, and delete based on the user's requests. Entries in red are automatically saved to the schoolserver. Entries in white are deleted (to the best of may understanding, resuming these entries is the same as launching from the home view so they essentially only clutter the journal). This mechanism gives a simple way for the user to control what is available when the XO is not connected to the schoolserver (after school, for example). It also protects the datastore in case the XO must be reflashed. Implementation requires that the DataManager activity runs as olpc (added to the activityfactory list) and that public keys and permissions be implemented on the schoolserver (something that a deployment should do when the XO registers with the schoolserver) I hope to see this activity get a live workout when I return to Nepal at the end of September. In the meantime, it is available for test and comment. Yours, Tony ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: DataManager version 1
Hi Tony,
This sounds like a great approach to managing backup. I particularly like
the color coding scheme and the way the user gets control over the process.
I wonder if this feature should be integrated into the Journal itself
somehow, or pehaps made into a control panel applet? It seems like doing
the work when you hit 'Stop' is inconsistent with the way other activities
function. A control panel applet would also get better privileges by
default.
I tried to launch DataManager as downloaded from ASLO but it hit an
exception. Attached is a patch which lets it get further through startup,
but it still fails looking for ~/.sugar/default/datastore/store. I'm not
familiar with the format of the datastore, or how it has changed in recent
Sugar versions.
Looking forward to seeing how this progresses. Let us know how it does in
Nepal!
Regards,
Wade
On Fri, Aug 28, 2009 at 1:38 PM, Tony Anderson t...@olenepal.org wrote:
Hi,
I posted the DataManager activity to ASLO today. It matches the code
currently on gitorious.
The intent of the DataManager is to deal with a problem faced in Nepal
which is the small size of the Nand. The current backup/restore feature
does not provide a way for the user to remove entries from the local store.
The activity works on 0.82 with the Nepal version of the schoolserver,
although I don't see why it wouldn't work with any version.
It works in three phases. At launch it builds a list from the schoolserver
(when connected) of all the entries. It provides a color code:
light green - entry not stored locally
green - entry stored locally (as well as on the schoolserver)
cyan - entry on the schoolserver in Commons
blue - entry from Commons stored locally
red - new entry not yet uploaded to the schoolserver
white - entry without an associated document
The status bar reports the number of entries in the datastore and the
percentage of the Nand in use.
In phase 2 the user can double-click on an entry. If it is on the local XO
(green or blue), it will be removed (but will still be on the schoolserver).
If it is not on the XO (light green or cyan), it will be downloaded to the
XO.
When the user clicks on the Stop button on the activity toolbar, the
activity performs the file operations: upload, download, and delete based on
the user's requests. Entries in red are automatically saved to the
schoolserver. Entries in white are deleted (to the best of may
understanding, resuming these entries is the same as launching from the home
view so they essentially only clutter the journal).
This mechanism gives a simple way for the user to control what is available
when the XO is not connected to the schoolserver (after school, for
example). It also protects the datastore in case the XO must be reflashed.
Implementation requires that the DataManager activity runs as olpc (added
to the activityfactory list) and that public keys and permissions be
implemented on the schoolserver (something that a deployment should do when
the XO registers with the schoolserver)
I hope to see this activity get a live workout when I return to Nepal at
the end of September. In the meantime, it is available for test and comment.
Yours,
Tony
From 5d52b0f699cb1c18bbeed3b363a014d73299d55d Mon Sep 17 00:00:00 2001
From: Wade Brainerd wad...@gmail.com
Date: Tue, 22 Sep 2009 14:10:39 +
Subject: [PATCH] Fixes for SoaS
Do not hard code the home directory.
Use the Sugar owner's public key as a serial number when the OLPC hardware
serial number is not available.
---
datamanager.py | 40 ++--
1 files changed, 34 insertions(+), 6 deletions(-)
diff --git a/datamanager.py b/datamanager.py
index 95fc039..612ed63 100644
--- a/datamanager.py
+++ b/datamanager.py
@@ -37,13 +37,14 @@ from time import strftime
import urllib2
from BeautifulSoup import BeautifulSoup
+HOMEPATH = path(os.environ['HOME'])
ACTIVITYPATH = path(activity.get_bundle_path())
DATAPATH = path(activity.get_activity_root()) / data
WORKPATH = DATAPATH / 'work'
KEYPATH = ACTIVITYPATH / '.ssh'
STOREPATH = path(/library/Datastore)
COMMONSPATH = path(/library/Commons)
-LOCALPATH = path(/home/olpc/.sugar/default/datastore/store)
+LOCALPATH = HOMEPATH / .sugar/default/datastore/store
DATEFORMAT = %Y-%m-%d %H:%M:%S
ACTIVITYTOOLBAR = 0
@@ -60,11 +61,16 @@ class DataManager(activity.Activity):
activity.Activity.__init__(self, handle)
self.set_title(Datamanager)
-f = open('/ofw/serial-number', 'r')
-t = f.read()
-f.close()
-SERIALNUMBER = t[:11]
+
+# Determine a unique serial number for this computer.
+SERIALNUMBER = self._get_serial_number()
+
+if not SERIALNUMBER:
+print Unable to determine a serial number.
+sys.exit(1)
+
print 'serial-number', SERIALNUMBER
+
quitflag = False
subprocess.call(mkdir -p + WORKPATH, shell=True)
DataManager version 1
Hi, I posted the DataManager activity to ASLO today. It matches the code currently on gitorious. The intent of the DataManager is to deal with a problem faced in Nepal which is the small size of the Nand. The current backup/restore feature does not provide a way for the user to remove entries from the local store. The activity works on 0.82 with the Nepal version of the schoolserver, although I don't see why it wouldn't work with any version. It works in three phases. At launch it builds a list from the schoolserver (when connected) of all the entries. It provides a color code: light green - entry not stored locally green - entry stored locally (as well as on the schoolserver) cyan - entry on the schoolserver in Commons blue - entry from Commons stored locally red - new entry not yet uploaded to the schoolserver white - entry without an associated document The status bar reports the number of entries in the datastore and the percentage of the Nand in use. In phase 2 the user can double-click on an entry. If it is on the local XO (green or blue), it will be removed (but will still be on the schoolserver). If it is not on the XO (light green or cyan), it will be downloaded to the XO. When the user clicks on the Stop button on the activity toolbar, the activity performs the file operations: upload, download, and delete based on the user's requests. Entries in red are automatically saved to the schoolserver. Entries in white are deleted (to the best of may understanding, resuming these entries is the same as launching from the home view so they essentially only clutter the journal). This mechanism gives a simple way for the user to control what is available when the XO is not connected to the schoolserver (after school, for example). It also protects the datastore in case the XO must be reflashed. Implementation requires that the DataManager activity runs as olpc (added to the activityfactory list) and that public keys and permissions be implemented on the schoolserver (something that a deployment should do when the XO registers with the schoolserver) I hope to see this activity get a live workout when I return to Nepal at the end of September. In the meantime, it is available for test and comment. Yours, Tony ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
