Difference between revisions of "Platform Team/Sugar Network/Architecture"

Revision as of 16:35, 17 December 2011

See also the introduction page and the basic concepts overview.

Summary

The technical decisions are tailored by:

Real needs of deployments like one-teacher schools in Peru and should be as simple as possible; Keep it simple, wise man!;
The system, from users point of view, should just work proving high-level services that cover the full collaboration circle that should exist within Sugar learning community;
The system should be useful not only for off-line environments, but also for cases in decent Internet connection.

Overview

The Sugar Network consists of different types of components:

Server side that provide API for clients:
- Mothersip server that keeps the whole Sugar Network information, clients might connect directly to this server (on-line case) or indirectly via distributed servers (off-line case);
- Optional distributed servers, contain a synchronised copy of central server (might be not for the entire Network to save storage space);
Client side:
- Client application that uses API to interact with a server;
- Client application that provides limited API to get access to the personal data.

Server

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

Mothership

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

Distributed 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.

Distributed services provide full featured API as the Mothership does. Distributed servers need to be synchronized.

Synchronisation

To let Network participant, connected to particular distributed server, interact with people from another distributed servers or with people from the Internet, distributed servers need to be synchronized.

Server might be synchronised:

With the Mothership, if connectivity presents;
With the Mothership or any other distributed servers via the Sneakernet.

Client

Client application is local, for reasons:

Originally, Sugar Network is being developed for deployments where teachers' XOs will be distributed 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;
It is all time possible to create Web application on the server side.

Default client

The default client is implemented using Web technologies to:

Make it possible to reuse Sugar Network in any Web browser in any Desktop Environment, i.e., not only from Sugar Shell;
Using existing Web methods might make frontend developing easier;
Involve Web developers to Sugar community;

It might sound a bit confusing to have local Web application, but this decision is based on:

Local Web applications serve only one user and are much simpler than singular applications that are intended to serve thousands of users simultaneously;
Having simple and clean designed code, it will be easy for doers to learn, change, reimplement the frontend.

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.

References

An OLPC wiki page about the Sneakernet.
Facebook's API.

@@ Line 5: / Line 5: @@
 The technical decisions are tailored by:
-* Real needs of deployments like [[Deployment_Team/Peru/Puno|one-teacher schools in Peru]] and should be as simple as possible; [[Wikipedia:KISS_principle|Keep it simple, wise man!]];
+* Real needs of deployments like [[Deployment_Team/Peru/Puno#The_problem|one-teacher schools in Peru]] and should be as simple as possible; [[Wikipedia:KISS_principle|Keep it simple, wise man!]];
 * The system, from users point of view, should just work proving high-level services that cover the full collaboration circle that should exist within Sugar learning community;
-* It is all about creating high-level services that use regular client-server interaction model with one addition, an optional need to make a synchronization between a distributed server and the main one, the Mothership; In other words, it is all time about having a chain of {{Code|Motherhip <-> [Distributed Server] <-> Client}} interactions;
+* The system should be useful not only for off-line environments, but also for cases in decent Internet connection.
 == Overview ==
-The Sugar Network consists of different types of parts:
+[[File:Sugar-networks-architecture.png|right]]
-* [[#Client|client side]], and
+The Sugar Network consists of different types of components:
-* [[#Server|server side]].
-The Sugar Network supports Internet and Internet-less environments. In both cases, the participant's experience is the same. The only difference is the amount of time when all contributors will see the same picture, in case of the Internet, it will happen in live mode, for Internet-less cases, after synchronizing all school servers.
+* [[#Server|Server side]] that provide [[Sugar_Network/API|API]] for clients:
+** [[#Mothersip|Mothersip]] server that keeps the whole Sugar Network information, clients might connect directly to this server (on-line case) or indirectly via distributed servers (off-line case);
+** Optional [[#Distributed_servers|distributed servers]], contain a [[#Synchronisation|synchronised]] copy of central server (might be not for the entire Network to save storage space);
+* [[#Client|Client side]]:
+** Client application that uses [[Sugar_Network/API|API]] to interact with a server;
+** Client application that [[#Personal_server|provides]] limited [[Sugar_Network/API|API]] to get access to the personal data.
 == Server ==
-In all cases the server API is the same for clients. But depending on connectivity, client might be connected to the Mothership or to an intermediate server.
+In all cases the server [[Sugar_Network/API|API]] is the same for clients. But depending on connectivity, clients might be connected to the [[#Mothership|Mothership]] or to an [[#Distributed_servers|intermediate server]].
-== Client ==
+=== Mothership ===
+The place where data is being collected from all distributed server. If clients have connectivity, they can connect to the Mothership to contribute to the Network directly.
+=== Distributed 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.
+Distributed services provide full featured [[Sugar_Network/API|API]] as the Mothership does. Distributed servers need to be [[#Synchronisation|synchronized]].
+=== Synchronisation ===
+To let Network participant, connected to particular [[#Distributed_servers|distributed server]], interact with people from another distributed servers or with people from the Internet, distributed servers need to be synchronized.
-Client application that runs on machines of people who take part in the Sugar Network. Its functionality is split into:
+Server might be synchronised:
-* [[#DBus_service|DBus service]], and
+* With the Mothership, if connectivity presents;
-* [[#Frontend|frontends]].
+* With the Mothership or any other distributed servers via the [[Wikipedia:Sneakernet|Sneakernet]].
-The frontends are lightweight, think about ''Web browsers vs. standalone applications'', that delegate the whole work to the DBus service that has high-level API. The reasons to do that are:
+== Client ==
-* Let it possible to create as many as people want frontends, trying to satisfy different types of purposes, full featured frontend, simple but-still-useful frontend, ''Hello, world!'' frontend to let other people create new one, etc.;
+Client application is local, for reasons:
-* Use DBus service API in Sugar activities to integrate them to the Sugar Network.
-=== DBus service ===
+* Originally, Sugar Network is being developed for deployments where teachers' XOs will be distributed 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;
+* It is all time possible to create Web application on the server side.
-=== Frontend ===
+=== Default client ===
-The default frontend implemented using Web technologies to:
+The default client is implemented using Web technologies to:
 * Make it possible to reuse Sugar Network in any Web browser in any Desktop Environment, i.e., not only from Sugar Shell;
@@ Line 44: / Line 65: @@
 * Involve Web developers to Sugar community;
-At the same time it is a local Web application. It sounds a bit confusing, but this decision is based on:
+It might sound a bit confusing to have local Web application, but this decision is based on:
 * Local Web applications serve only one user and are much simpler than singular applications that are intended to serve thousands of users simultaneously;
 * Having simple and clean designed code, it will be easy for doers to learn, change, reimplement the frontend.
+=== Personal server ===
+This local application provides limited [[Sugar_Network/API|API]] to get access to:
+* Private data in user's home directory,
+* Data accessible from removable devices like USB sticks or SD cards.
 == References ==