[Sugar-devel] Sugar-Server enhancement

[Tony Anderson]

Hi, Jerry

/library/user/<some_id_here> refers to the directory on the school server.

Currently, the store on the school server is a metadata file and a 
document file in the Journal directory per Journal object. The Log 
directory contains the
metadata file for Journal objects without a document.

The script stores and retrieves using sftp with authentication by 
public/private key.

Day-by-day control is by using the 'favorite' star in the Journal (in 
the metadata, the 'keep' flag). It is set, if there is a local (on the 
XO) copy of the document.
It is clear, if there is no local copy. The user can set the flag which 
causes the script to download it to make a local copy. The user can 
clear to request the local copy to be deleted.

There will be need for a 'recovery' mode in the case of a reflashed XO, 
for example. Currently, that is envisioned as a 'sync' option which 
forces the
script to download any metadata files in the server 'Journal' directory 
which are not present in the local copy. The keep star would be cleared 
for these
objects, but the user could then selectively download copies of the 
document file. I am not sure of the performance cost, but this could be 
done by the script as a normal step.

Tony

On 04/15/2016 11:36 PM, Jerry Vonau wrote:
>
>> On April 15, 2016 at 3:37 AM Tony Anderson <tony_anderson at usa.net> wrote:
>>
>>
>> Hi, Jerry
>>
>> I am not sure what you mean by 'remote network datastore'.
>>
> The objects that are not stored as part of the local journal would need to
> live somewhere, you have being referring to '/library/user/<some_id_here>'
> as being the place for that. I view that location as 'remote network
> datastore' because that location holds all the objects not on the client XO
> but can be retrieved. The older objects can be retrieved right? Or are the
> objects being stored in more of a warehouse like fashion with no access
> from the clients?
>
> Jerry
>
>
>> 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 at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
> .
>