Platform Team/Sugar Network/Architecture

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;
• 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 was 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 on a client side;
• It is all time possible to create Web application on a server side.

Default client

The default client is implemented using Web technologies to:

• Using Web technologies might make client developing easier;
• Make it possible to reuse Sugar Network in any Web browser in any Desktop Environment, i.e., not only from Sugar Shell;
• It might be easier to find potential Sugar contributors within Web developers rather than developers who know GTK.

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 multiple users simultaneously;
• It might be useful to design simple and clean code using existing Web technics like MVC;
• Thus, it will be easier for doers to learn, change, reimplement the new clients.

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.