Hi, Jerry
I am not sure what you mean by 'remote network datastore'.
What I am doing now is looking at each Journal object. If is is new
(doesn't have Journal in the metadata - Journal showing the
item has been backed up to the school server), the script uses sftp to
upload it to /library/user/journal (create_user adds two directories,
journal and log.) and saves 'journal' in the metadata.
Actually, there is an additional check to make sure the document in the
new object has a 'user-supplied' title. If not, the object is saved to
the log (without the document).
An new object which does not have an associated document with a
user-supplied title has the metadata file uploaded to the
/library/user/serial-number/log directory. The local copy of the object
is deleted.
Currently, there is a design flaw in Sugar so that when an activity is
resumed, the object_id is used. This means that the activity overwrites
the original. I don't remember if I deal with an updated object which
should be saved again to the server.
The script checks the 'keep' flag in the metadata. If it is set and the
document in not in the local datastore, it is downloaded (sftp).
If it is not set and the document is in the local datastore, it is deleted.
The idmgr 'create_user' does need to be tweaked. Currently, I modified
it to create the extra directories.
One concern is with the 'small' servers. Will they have space to backup
Journal objects? At one point OLPC estimated 2GB per XO as the space
required to backup the Journal. For a 100 XO deployment, 200GB seems
reasonable against a 1TB drive. Fortunately, the industry enables use of
larger drives with only a small penalty in price. (Actually on Amazon,
the cost per GB seems constant).
Tony
On 04/15/2016 04:12 PM, Jerry Vonau wrote:
Or something like a remote network datastore if I understand what Tony is
in favor of.
_______________________________________________
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
