Platform Team/Sugar Network/Architecture: Difference between revisions

(36 intermediate revisions by 2 users not shown)

Line 1:

~~See also~~ [[~~Platform_Team~~/~~Sugar_Network~~|~~introduction page~~]] ~~and~~ [[~~Platform_Team/~~Sugar_Network~~/Concept~~|~~basic concepts overview~~]].

This is a twin page of Sugar Network's [[Sugar_Network/Concept|basic concepts]] from technical point of view. See also the [[Sugar_Network|introduction page]].

== ~~Summary~~ ==

== Overview ==

=== Functioning ===

The only worfklow within the Sugar Network from the technical point of view is:

* Clients create, modify and browse different types of resources ([[Sugar_Network/Concept#Resources|resources]] from conceptual point of view, [[Platform_Team/Sugar_Network/API#Resources|resources]] from the API point of view) on a server;

* If this server is a [[#Node_servers|Node]] server, the system will take care about [[#Synchronization|synchronizing]] its resources with other Node servers and, finally, with the central one, the [[#Master_server|Master]] server.

=== Components ===

This is technical view on [[Sugar_Network/Concept#Overview|three levels]] of the Sugar Network:

~~The technical decisions are tailored by:~~

* [[#Server|Server side]],

* [[#Conceptual_level|Conceptual level]],

* [[#Client|Client side]].

* The particular technical implementation is fully driven by real needs of deployments like [[Deployment_Team/Peru/Puno|one-teacher schools in Peru]] and should be as simple as possible;<br>[[Wikipedia:KISS_principle|Keep it simple, wise man!]];

== Server ==

* 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; 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~~ ==

[[File:Sugar-networks-architecture.png|right]]

Server side is represented by:

* [[#Master_server|Master]] server that keeps the whole Sugar Network information, clients might connect directly to this server (on-line case) or indirectly via Node servers (off-line case);

* Optional [[#Node_servers|Node]] servers, contain a [[#Synchronization|synchronised]] copy of central server (might be not for the entire Network to save storage space);

In all cases the server [[Platform_Team/Sugar_Network/API|API]] is the same for clients. But depending on connectivity, clients might be connected to the [[#Master_server|Master]] server or to a [[#Node_servers|intermediate server]].

=== Master server ===

The place where data is being collected from all Node servers. If clients have connectivity, they can connect to the Master to contribute to the Network directly.

=== Node 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.

Node servers provide full featured [[Platform_Team/Sugar_Network/API|API]] as the Master does. Nodes need to be [[#Synchronization|synchronized]].

== Conceptual level ==

This is how Sugar Network looks like on [[Sugar_Network/Concept|conceptual level]] represented by the [[Platform_Team/Sugar_Network/API|API]].

=== Objects model ===

The model refers to the following additional information:

=== Simplified editing workflow ===

The system is designed to be as lightweight as possible to make it running on XO laptops in unmaintainable environments and simplify synchronization. So, the following design decisions were taken:

* No history for Sugar Network objects, only events about made changes;

* Only object author(s) can process editing;

* But, other people can suggest changes (that might be implemented on client side in pretty powerful way, e.g., people can change objects but it will be postponed for later author(s)' review).

That might be changed but only after making system one level more complicated.

== Client ==

This is what Network participants are interacting with. This is a software that let people get access to the Sugar Network and define how Sugar Network should look like from users point of view. User experience, that these clients provide, might be too different from a client to a client. Starting from a couple of elements in the already existing software's [[Wikipedia:Graphical_user_interface|GUI]] (when people even don't suspect they are interacting with the Sugar Network) and ending with clients that represent conceptual level as close as possible.

Client side is represented by:

* Client application that uses [[Platform_Team/Sugar_Network/API|API]] to interact with a server;

* Client application that [[#Personal_server|provides]] limited [[Platform_Team/Sugar_Network/API|API]] to support server-less workflow.

Client application is local, for reasons:

* Originally, Sugar Network was being developed for deployments where teachers' XOs will be Node 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.

=== Personal server ===

This local application provides limited [[Platform_Team/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.

== Synchronization ==

To let Network participant, connected to particular [[#Node_servers|Node server]], interact with people from another Node servers or with people from the Internet (Master server), Node servers need to be synchronized.

Server might be synchronized:

~~The Sugar Network consists of different types of parts~~:

* With the Master, if connectivity presents;

* With the Master or any other Node servers via the [[Wikipedia:Sneakernet|Sneakernet]].

* Client application that runs in Sugar learning environment on machines of people who take part in the Sugar Network;

== Getting involved ==

* 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:~~

== References ==

~~# Client side functionality is split into DBus service and frontends;~~

* An [http://wiki.laptop.org/go/Sneakernet OLPC wiki page] about the [[Wikipedia:Sneakernet|Sneakernet]].

~~# Frontends are lightweight to let it possible to implement new frontend in fast manner, or, use DBus service partially in, e.g., Sugar activities;~~

~~# 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;~~

~~# 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~~.

@@ Line 1: / Line 1: @@
-See also [[Platform_Team/Sugar_Network|introduction page]] and [[Platform_Team/Sugar_Network/Concept|basic concepts overview]].
+This is a twin page of Sugar Network's [[Sugar_Network/Concept|basic concepts]] from technical point of view. See also the [[Sugar_Network|introduction page]].
-== Summary ==
+== Overview ==
+=== Functioning ===
+The only worfklow within the Sugar Network from the technical point of view is:
+* Clients create, modify and browse different types of resources ([[Sugar_Network/Concept#Resources|resources]] from conceptual point of view, [[Platform_Team/Sugar_Network/API#Resources|resources]] from the API point of view) on a server;
+* If this server is a [[#Node_servers|Node]] server, the system will take care about [[#Synchronization|synchronizing]] its resources with other Node servers and, finally, with the central one, the [[#Master_server|Master]] server.
+=== Components ===
+This is technical view on [[Sugar_Network/Concept#Overview|three levels]] of the Sugar Network:
-The technical decisions are tailored by:
+* [[#Server|Server side]],
+* [[#Conceptual_level|Conceptual level]],
+* [[#Client|Client side]].
-* The particular technical implementation is fully driven by real needs of deployments like [[Deployment_Team/Peru/Puno|one-teacher schools in Peru]] and should be as simple as possible;<br>[[Wikipedia:KISS_principle|Keep it simple, wise man!]];
+== Server ==
-* 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; 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 ==
+[[File:Sugar-networks-architecture.png|right]]
+Server side is represented by:
+* [[#Master_server|Master]] server that keeps the whole Sugar Network information, clients might connect directly to this server (on-line case) or indirectly via Node servers (off-line case);
+* Optional [[#Node_servers|Node]] servers, contain a [[#Synchronization|synchronised]] copy of central server (might be not for the entire Network to save storage space);
+In all cases the server [[Platform_Team/Sugar_Network/API|API]] is the same for clients. But depending on connectivity, clients might be connected to the [[#Master_server|Master]] server or to a [[#Node_servers|intermediate server]].
+=== Master server ===
+The place where data is being collected from all Node servers. If clients have connectivity, they can connect to the Master to contribute to the Network directly.
+=== Node 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.
+Node servers provide full featured [[Platform_Team/Sugar_Network/API|API]] as the Master does. Nodes need to be [[#Synchronization|synchronized]].
+== Conceptual level ==
+This is how Sugar Network looks like on [[Sugar_Network/Concept|conceptual level]] represented by the [[Platform_Team/Sugar_Network/API|API]].
+=== Objects model ===
+{{:Platform_Team/Sugar_Network/Objects_model}}
+The model refers to the following additional information:
+=== Simplified editing workflow ===
+The system is designed to be as lightweight as possible to make it running on XO laptops in unmaintainable environments and simplify synchronization. So, the following design decisions were taken:
+* No history for Sugar Network objects, only events about made changes;
+* Only object author(s) can process editing;
+* But, other people can suggest changes (that might be implemented on client side in pretty powerful way, e.g., people can change objects but it will be postponed for later author(s)' review).
+That might be changed but only after making system one level more complicated.
+== Client ==
+This is what Network participants are interacting with. This is a software that let people get access to the Sugar Network and define how Sugar Network should look like from users point of view. User experience, that these clients provide, might be too different from a client to a client. Starting from a couple of elements in the already existing software's [[Wikipedia:Graphical_user_interface|GUI]] (when people even don't suspect they are interacting with the Sugar Network) and ending with clients that represent conceptual level as close as possible.
+Client side is represented by:
+* Client application that uses [[Platform_Team/Sugar_Network/API|API]] to interact with a server;
+* Client application that [[#Personal_server|provides]] limited [[Platform_Team/Sugar_Network/API|API]] to support server-less workflow.
+Client application is local, for reasons:
+* Originally, Sugar Network was being developed for deployments where teachers' XOs will be Node 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.
+=== Personal server ===
+This local application provides limited [[Platform_Team/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.
+== Synchronization ==
+To let Network participant, connected to particular [[#Node_servers|Node server]], interact with people from another Node servers or with people from the Internet (Master server), Node servers need to be synchronized.
+Server might be synchronized:
-The Sugar Network consists of different types of parts:
+* With the Master, if connectivity presents;
+* With the Master or any other Node servers via the [[Wikipedia:Sneakernet|Sneakernet]].
-* Client application that runs in Sugar learning environment on machines of people who take part in the Sugar Network;
+== Getting involved ==
-* 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.
+{{:Sugar_Network/Feedback}}
-The particular technical implementation is tailored by the following decisions:
+== References ==
-# Client side functionality is split into DBus service and frontends;
+* An [http://wiki.laptop.org/go/Sneakernet OLPC wiki page] about the [[Wikipedia:Sneakernet|Sneakernet]].
-# Frontends are lightweight to let it possible to implement new frontend in fast manner, or, use DBus service partially in, e.g., Sugar activities;
-# 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;
-# 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.