Platform Team/Sugar Network/Implementation

Sugar Network version cycle: | 1.0 |

Summary

The design and implementation are tailored by the following intentions:

Implementation should be as lightweight as possible to run all components on restricted hardware like XO laptops;
Minimize any maintaining costs as much as possible to use Sugar Network in environments like offline schools where the only maintainers are not IT skilled people;
Assume decentralization scheme when Sugar Network nodes might be started on different servers with further online or offline synchronization with the master.

To accomplish above tasks, Sugar Network content is handled by the active-document library which uses Xapian to index content and simple filesystem storage (might be changed in the future).

Sugar Network is represented by two major applications to run on Sugar Network node or users side:

sugar-network-node, and,
sugar-network-client.

In both cases, applications provide RESTful API as the only access point for outer usage. Any end users related functionality implemented in Sugar Network clients on top of API providers.

sugar-network-node

This application provides Sugar Network server functionality. Such functionality served via the Sugar Network API.

The configuration occurs based on several sources (sorted by applied order):

Command-line arguments (configuration names equal to command-line arguments),
/etc/sugar-network/config system-wide configuration file,
~/.config/sugar-network/config user-wide configuration file.

To get the current configuration, call:

sugar-network-node config

The major configuration options are:

[node]
# path to a directory to place server data
data-root = /var/lib/sugar-network

# hostname to listen for incomming connections and using for publicly visible urls
host = 0.0.0.0

# port number to listen incomming connections
port = 8000

Note that `sugar-network-node` needs OpenSSH-5.6 or later to verify users' credentials. If you don't have such version, enable `--trust-users` to disable any verification:

[node]
# switch off user credentials check; disabling this option will require OpenSSH-5.6 or later
trust-users = True

Assuming that configuration was set properly, use the following commands to manipulate `sugar-network-node` daemon:

sugar-network-node start
sugar-network-node stop
sugar-network-node status

To run application in the foreground instead of switching to daemon mode, call:

sugar-network-node -F start

Optionally (next releases might have WebUI as a separate application), it is possible to run Web UI client from the same process if the following configuration options were set:

[webui]
# start web application to serve Sugar Network content
webui = True

# hostname to bind
webui-host = 0.0.0.0

# address to listen for Web clients
webui-port = 5000

sugar-network-client

This is a client side application. The reasons to have such client application (instead of direct using of server API) are the following:

Provide access to local Sugar Network data (providing API from the localhost), it is useful if server is not accessible;
Having locally provided API as a proxy to a server, it is the only way (for now) to be authenticated on the server;
Provide features that can't served from a servers, e.g., launching activities;
Keeping in mind two previous points, run Web UI and Contributor Hub clients locally.

The configuration occurs based on several sources (sorted by applied order):

Command-line arguments (configuration names equal to command-line arguments),
/etc/sweets.conf system-wide configuration file,
~/.config/sweets/config user-wide configuration file,
~/.sugar/current-profile/sweets.conf configuration specific to a Sugar profile.

To get the current configuration, call:

sugar-network-client config

The major configuration options are:

[client]
# url to connect to Sugar Network server API
api-url = http://api-testing.network.sugarlabs.org

# port number to listen for incomming connections from IPC clients
ipc-port = 5001

# path to Contributor Hub site directory to serve from /hub location for IPC
# clients to workaround lack of CORS for SSE while using Hub from file:// url
hub-root = /usr/share/sugar-network/hub

[webui]
# start web application to serve Sugar Network content
webui = False

# hostname to bind
webui-host = 127.0.0.1

# address to listen for Web clients
webui-port = 5000

Contributor Hub is a pure JavaScript application, i.e., it is possible to open it in a Web browser from local files system. But since Server-sent events doesn't support Cross-origin resource sharing, Contributor Hub has to be provided from the same locations as API, here, from /hub path:

http://localhost:5000/hub

Usage

Assume we have two hosts, Node and Client (it might be the same real host though). Node host will be a Sugar Network node server. Client will be user's side with running Sugar Network ready Sugar Shell to connect to the Node. Attach Factory Sweets Distribution repository on both hosts.

On the Node side:

Install sugar-network package;
Populate /etc/sugar-network/config configuration file with the following content:

[node]
host = 0.0.0.0
port = 8000

Run node server using the sugar-network-node start command;

On the Client side:

Install sweets-desktop package;

Point Client to newly launched Node (you all time can point Client to public servers) in the /etc/sweets.conf configuration file:

[client]
api-url = http://NODE-HOST-HERE:8000

Choose Sweets Distribution login session or run Sugar in a window using the sweets-sugar-emulator command;

Enable Sugar Network integration in the Shell;

Open Web UI by pressing F8 key;

Find Contributor Hub in the Web UI and launch it.

Note that newly installed Node will be empty, the process of populating it with public data will be implemented in upcoming release.

Sources

Clone sources from Git repository:

git clone git://git.sugarlabs.org/network/network.git --recurse-submodules

Getting involved

Submit your bug report or feature request.
Browse our implementation discussions, and post your feedback. (You should join this discussion list in order to avoid having your messages postponed for moderation.)