DataManager version 1
tony at olenepal.org
Wed Sep 23 10:33:58 EDT 2009
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
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).
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!
> On Fri, Aug 28, 2009 at 1:38 PM, Tony Anderson <tony at olenepal.org
> <mailto:tony at olenepal.org>> wrote:
> 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
> 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.
More information about the Devel