[Sugar-devel] Sugar-Server enhancement

[Tony Anderson]

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.