Platform Team/Sugar Network/Architecture

See also introduction page and basic concepts overview.

Summary

The technical decisions are tailored by:

• The particular technical implementation is fully driven 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 application that runs in Sugar learning environment on machines of people who take part in the Sugar Network;
• Server that runs either in the Internet (if connectivity is not a problem for clients) or on a school server (that is being synchronized with the Internet, thus, with the rest of school servers).

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.

The particular technical implementation is tailored by the following decisions:

1. Client side functionality is split into DBus service and frontends;
2. Frontends are lightweight to let it possible to implement new frontend in fast manner, or, use DBus service partially in, e.g., Sugar activities;
3. Using Web technologies to implement the default frontend:
   • 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;
4. Keep default frontend as a local Web application on a client side, it sounds converse regarding the #3, 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 (see the previous point), it will be easy for doers to learn, change, reimplement the front end.