Platform Team/Sugar Network/Architecture

From Sugar Labs
Jump to navigation Jump to search

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

Sugar-networks-architecture.png

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

Retrieved from "https://wiki.sugarlabs.org/index.php?title=Platform_Team/Sugar_Network/Architecture&oldid=73327"