Platform Team/Sugar Network/Architecture: Difference between revisions

Line 15:

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

* [[#Client|client side]], and

* 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)~~.

* [[#Server|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.

~~The particular technical implementation is tailored by the following decisions:~~

== Server ==

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

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.

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

Todo:

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

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

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

== Client ==

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

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

* [[#DBus_service|DBus service]], and

* [[#Frontend|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.

=== DBus service ===

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

@@ Line 15: / Line 15: @@
 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;
+* [[#Client|client side]], and
-* 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).
+* [[#Server|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.
-The particular technical implementation is tailored by the following decisions:
+== Server ==
-# Client side functionality is split into DBus service and frontends;
+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.
-# 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:
+Todo:
-#* 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;
+:* 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.
-#* 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:
+== Client ==
-#* 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.
+Client application that runs on machines of people who take part in the Sugar Network. Its functionality is split into:
+* [[#DBus_service|DBus service]], and
+* [[#Frontend|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.
+=== DBus service ===
+=== 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.