Platform Team/Sugar Network/Architecture

This is a twin page of Sugar Network's basic concepts from technical point of view. See also the introduction page.

Functioning
The only worfklow within the Sugar Network from the technical point of view is:


 * Clients create, modify and browse different types of resources (resources from conceptual point of view, resources from the API point of view) on a server;
 * If this server is a Node server, the system will take care about synchronizing its resources with other Node servers and, finally, with the central one, the Master server.

Components
This is technical view on three levels of the Sugar Network:


 * Server side,
 * Conceptual level,
 * Client side.

Server


Server side is represented by:


 * Master server that keeps the whole Sugar Network information, clients might connect directly to this server (on-line case) or indirectly via Node servers (off-line case);
 * Optional Node servers, contain a synchronised copy of central server (might be not for the entire Network to save storage space);

In all cases the server API is the same for clients. But depending on connectivity, clients might be connected to the Master server or to a intermediate server.

Master server
The place where data is being collected from all Node servers. If clients have connectivity, they can connect to the Master to contribute to the Network directly.

Node servers
Servers that will be useful if:


 * there is no connectivity at all;
 * connectivity is sporadic;
 * connectivity is not cheap and its usage needs to be minimized.

Node servers provide full featured API as the Master does. Nodes need to be synchronized.

Conceptual level
This is how Sugar Network looks like on conceptual level represented by the API.

Objects model
The model refers to the following additional information:

Simplified editing workflow
The system is designed to be as lightweight as possible to make it running on XO laptops in unmaintainable environments and simplify synchronization. So, the following design decisions were taken:


 * No history for Sugar Network objects, only events about made changes;
 * Only object author(s) can process editing;
 * But, other people can suggest changes (that might be implemented on client side in pretty powerful way, e.g., people can change objects but it will be postponed for later author(s)' review).

That might be changed but only after making system one level more complicated.

Client
This is what Network participants are interacting with. This is a software that let people get access to the Sugar Network and define how Sugar Network should look like from users point of view. User experience, that these clients provide, might be too different from a client to a client. Starting from a couple of elements in the already existing software's GUI (when people even don't suspect they are interacting with the Sugar Network) and ending with clients that represent conceptual level as close as possible.

Client side is represented by:


 * Client application that uses API to interact with a server;
 * Client application that provides limited API to support server-less workflow.

Client application is local, for reasons:


 * Originally, Sugar Network was being developed for deployments where teachers' XOs will be Node servers, thus, it will be useful to delegate some of computing to students' XOs;
 * Stimulate doing behaviour when it should be possible to create new client application or tweak existing on a client side;
 * It is all time possible to create Web application on a server side.

Personal server
This local application provides limited API to get access to:


 * Private data in user's home directory,
 * Data accessible from removable devices like USB sticks or SD cards.

Synchronization
To let Network participant, connected to particular Node server, interact with people from another Node servers or with people from the Internet (Master server), Node servers need to be synchronized.

Server might be synchronized:


 * With the Master, if connectivity presents;
 * With the Master or any other Node servers via the Sneakernet.