Features/Transfer to many options

Proposal for a client-initiated journal transfer (1-to-N feature)

Note that the initial "Browse" based solution (of which comments have been struck out) cannot fill the purpose, because of the following reasons

• (Thanks Anish) "Browse" based solution only allows files to be downloaded. But Sugar's entries are more than just a file - they are a combination of metadata, and data (files). Eg. - Turtle Art Journal entry.
• (Thanks Anish and Daniel) Mounting the server's shares' entries locally, also conforms to the Sugar look-and-feel.

Workflow

• The server XO would make its shares available via WebDAV, running in the context of "httpd" service.
• The client XO would connect to the server XO via its browser.
• Therafter, "Browse" would take over.
• The client would mount the server's share locally.
• Thereafter, the server's share's contents can be "copied" from, just as if it was just another local filesystem.

Details

• Setting up WebDAV on a server XO.
  • Install package "httpd".
  • Generate openssl "server.crt" and "server.key".

       cd /etc/ssl/certs/
       sudo openssl req -new -newkey rsa:1024 -days 365 -nodes -x509 -keyout ssl.key -out ssl.crt

• • Configure "/etc/httpd/conf.d/ssl.conf" "/etc/httpd/conf/httpd.conf" to setup the WebDAV share. Sample file : media:httpd.conf
    • Firstly, this sets up the paths "SSLCertificateFile" and "SSLCertificateKeyFile", which are required for HTTPS over SSL.
    • SecondlyThis sets up "/var/www/web1/web" as the "webdav" folder. In other words, whetever entries are present in this folder, will be made available for the client XOs.
  • Generate authentication file for the webdav folder. These user-password credentials will be asked whenever a client tries to access the webdav folder. For example, the following list of commands sets "test" as the user, and "olpc" as the password.

       sudo htpasswd -c /var/www/web1/passwd.dav test
       New password:  <olpc>
       Re-type new password:  <olpc> 
       Adding password for user test

• • Start service "httd".
  • ALL THESE STEPS WOULD BE DONE AS PART OF OOB STAGE.

• [User-Workflow] Exporting Data to WebDav, on a server XO.
  • Add "Share" listview in the bottom panel-tray; that would make a total of 4 types of listview - Journal, Documents, Mounted-Drives, Share.
  • "Share" would follow all the schematics of "Documents" type. After all, "Share" is just a folder in the filesystem (like "Documents").
  • The corresponding folder is "/var/www/web1/web" (as configured in "/etc/httpd/conf.d/ssl.conf").
  • All entries in the "Share" folder would be available to client XOs.

• [Code-Requirements] Exporting Data to WebDav, on a server XO.
  • "Share" listview needs to be added on the lines of "Documents" listview. Code-reuse should be done as much as possible. Ideally, there should just be a difference of the "folder-path".

• [User-Workflow] Client XO wishes to access the share of Server XO.
  • Navigates to the "Neighborhood" view.
  • Hovers over the "Server" buddy.
  • The popup appears, which has a new entry "Access Share" (in addition to "Make Friend").
  • Clicks on "Access Share".
  • The "Browser" activity opens, with the url pointing to the "Server" buddy's webdav share.
  • Thereafter, client may navigate the webdav directory hierarchy, or download files (all of which is already built in the "Browse" activity). Most importantly, there is the "Keep Link" feature in "Browse", which nicely downloads the webdav-entry, and promptly saves it in the "Journal" - something that happens in the "Send To" feature as well.
  • The server's share is mounted. A color-specific buddy-icon in the bottom tray signifies it. Clicking this icon displays the server's share's entries, on the lines of Journal/Documents/Shares/Mounted-Drives.
  • Now, the entries can be copied from the mounted folder, to Journal/Documents/Shares/Mounted-Drives.

• [Code-Requirements] Client XO wishes to access the share of Server XO.
  • Mapping a neighborhood-buddy to its IP Address
    • Luckily, in the method "def __buddy_updated_cb(self, account, contact_id, properties):" in "jarabe/model/neighborhood.py", there is the "properties['ip4-address']", which contains the IP address of the buddy. All that is needed is to persist it in the "BaseBuddyModel" in "jarabe/model/buddy.py".
    • When the client clicks on "Access Share" on the buddy, this IP Address can be easily retreived, and the URI formed "https://<IP Address>/webdav"
  • Opening up the server's webdav
    • The generated URI would be passed to the "Browse" activity; and thereafter, "Browse" would take over.
  • A minor query, regarding the last point, has been posted at http://lists.sugarlabs.org/archive/sugar-devel/2012-April/036425.html. (For resolving this, some additional code may have to be written, but that is something perfectly doable. However, currently awaiting a reply, to see if the code for this already exists :-) ).

[Server 1] Launch "Turtle Art"

[Server 1] Modify "Turtle Art" workspace and then "Close".

[Server 1] Initially, "Shares" is empty.

[Server 1] Copy "Turtle Art" journal entry, to "Shares".

[Server 2] Launch "Turtle Art"

[Server 2] Modify "Turtle Art" workspace and then "Close".

[Server 2] Initially, "Shares" is empty.

[Server 2] Copy "Turtle Art" journal entry, to "Shares".

[Client] Server-1 and Server-2 buddy icons in Neighborhood-view.

[Client] Click on Server-1's "Access Share".

[Client] Notification icon appears at botton, signifying that the remote share has been locally mounted.

[Client] Click on Server-2's "Access Share".

[Client] Notification icon appears at bottom, signifying that the remote share has been locally mounted.

[Client] Initially, "Journal" is empty.

[Client] Click on Server-1's share.

[Client] Download-and-Copy the entry to Journal.

[Client] Click on Server-2's share.

[Client] Download-and-Copy the entry to Journal.

[Client] Server-1's Turtle-Art entry, successfully replicated at client.

[Client] Server-2's Turtle-Art entry, successfully replicated at client.

[ARCHIVE] Possible options

In a server-initiated operation, the server is responsible for adequate delivery to all the clients, whatever the number may be. In a client-initiated operation, each client is responsible for herself only.

Option	Server-Initiated / Client-Initiated	Secure Data Transfer	Proxy Support	Peer to Peer Support (Gabble/Salut)
Looping over "Send To"	Server-Initiated			Yes/Yes
Sascha's JournalToWebDAV	Client-Initiated
Each XO acts as an independent WebDAV server; client uses browser	Client-Initiated	Yes (HTTPS over SSL)		/Yes