Platform Team/Sugar Network/Architecture

See also introduction page and 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;
• 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 Motherhip <-> [Distributed Server] <-> Client interactions; Because:
  • Only on the Mothership level, there could be skilled people that can follow not trivial way to solve possible issues;
  • Thus, either system should be smart enough to solve issues on its own or it should be as simple as possible delegating not trivial work to the Mothership; The 2nd option is taken;

Overview

The Sugar Network consists of different types of parts:

• client side, and
• 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

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.

Todo:

• Would be useful to involve, in automatic manner, clients, i.e., like in case of VCS; client can work with the server or with local replication that needs to be pushed to the server when client will be online.

Client

Client application that runs on machines of people who take part in the Sugar Network. Its functionality is split into:

• DBus service, and
• frontends.

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:

• 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.;
• Use DBus service API in Sugar activities to integrate them to the Sugar Network.

Frontend

The default frontend 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;

At the same time it is a local Web application. It sounds a bit confusing, 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.

References

• An OLPC wiki page about the Sneakernet.