18
edits
Changes
Jump to navigation
Jump to search
Created page with 'Activities in Sugar may employ the Telepathy framework to implement collaborative behaviors over the network. The messages sent between participating Activities may be routed th…'
Activities in Sugar may employ the Telepathy framework to implement collaborative behaviors over the network. The messages sent between participating Activities may be routed through a server, when using Telepathy's XMPP backend (Gabble), or they may be routed directly from the sender to the receiver, when using Telepathy's Link-local XMPP backend (Salut). Communication with Telepathy occurs over D-Bus, using the Telepathy D-Bus API.
Programs written in Javascript+HTML+CSS, designed to run in a browser, can also provide online collaborative behaviors, as evidenced most famously by Google Docs. However, this collaboration typically requires a cooperating central server, because the standard browser security model does not permit a javascript application to communicate directly with any computer other than the server.
This page presents a simple design to enable decentralized, serverless collaboration between javascript applications. This model also extends naturally to environments in which a central server is available.
==Architecture Overview==
WebCollab employs a server, the HTTPCollab server. The javascript webpage interacts with this server by downloading files from it and uploading files to it. For a single central server, that's all there is to it.
To enable decentralized operation, such as would be expected when using Telepathy, the servers talk to each other. Every time a local user uploads a file to the local server, the local server transmits the file to all the other servers, which make it available at the same path. Javascript clients are expected to poll directories that may contain messages in which they are interested, so the system acts as a message-passing interface with named messages. A client that uploads a file can reasonably expect that all other clients will soon become aware of that file's existence.
Common web browsers typically permit javascript programs to communicate only with the server from which they were downloaded. Therefore, it may be necessary to download the javascript program, or at least a portion of it, from the HTTPCollab server.
==The Type-0 HTTPCollab Server->Client Interface==
In the simplest case, the Server exposes an interface that is simply HTTP/1.1, specifically GET, PUT, and DELETE. Some directory on the server (e.g. http://karmashare.sugarlabs.org/schools/GPA/group22/collabdir/) is selected as the "collaboration directory", and the server is configured to accept PUT and DELETE within this directory. To avoid interference by malicious actors PUTing gigabytes of data or DELETEing indiscriminately, it may be appropriate to employ an access control mechanism such as an HTTP cookie.
As far as a simple server is concerned, this describes its entire interaction with the client.
==The Type-0 JSCollab Client->Server Interface==
The server allows the client to upload arbitrary files, and every webapp can make use of this system as pleases its authors. However, a simple structure may provide a valuable scaffolding on which to build more complex systems. JSCollab describes one such simple client-side behavior.
A JSCollab client has a unique id during each session. This id may be a random string, and it need not be the same from session to session. The id must be a valid HTTP path name and must not contain the characters "_" or "/".
A message in JSCollab has a key, a value, and an index. The key is a string subject to the same constraints as the unique id. The value is a sequence of arbitrary bytes. The index is an integer indicating the number of messages previously sent by the user, incremented for each message, starting at 0.
To broadcast a message, a JSCollab client uploads a file with the name {unique id}_broadcast_{index}_{key}. The contents of the file are the value of the message. The index is represented as a base-10 string.
To send a message to a specific user specified by a target id, the client uploads a file with the name {unique id}_to_{target id}_{index}_{key}
For efficiency reasons, it may sometimes be appropriate to delete messages. A client may delete messages using the HTTP DELETE command. Because messages always have unique names, there is
==The Type-0 SugarHTTPCollab Server->Server Interface==
In the case of Sugar and Telepathy, the server runs on localhost, and acts as an interface to Telepathy. When the activity is initiated, the server is launched on any open port on localhost, and the browser is pointed at a known url on the host (e.g. http://localhost:42141/index.html) from which to download the first page. The javascript is already aware of the collaboration directory URL (e.g. http://localhost:42141/collabdir/).
The server is configured to accept all PUT and DELETE requests in collabdir/. If the activity is already shared, the PUT or DELETE request is immediately also transmitted to all other collaborating server instances.
When a new server joins, it must be informed of the current state of collabdir/. This is easy to do in a simple way; just pick a random participant upon joining and ask for the complete contents. Performing this update in a reliable and efficient manner is nontrivial, but should be possible. A sophisticated implementation is probably not necessary for a first release.
Programs written in Javascript+HTML+CSS, designed to run in a browser, can also provide online collaborative behaviors, as evidenced most famously by Google Docs. However, this collaboration typically requires a cooperating central server, because the standard browser security model does not permit a javascript application to communicate directly with any computer other than the server.
This page presents a simple design to enable decentralized, serverless collaboration between javascript applications. This model also extends naturally to environments in which a central server is available.
==Architecture Overview==
WebCollab employs a server, the HTTPCollab server. The javascript webpage interacts with this server by downloading files from it and uploading files to it. For a single central server, that's all there is to it.
To enable decentralized operation, such as would be expected when using Telepathy, the servers talk to each other. Every time a local user uploads a file to the local server, the local server transmits the file to all the other servers, which make it available at the same path. Javascript clients are expected to poll directories that may contain messages in which they are interested, so the system acts as a message-passing interface with named messages. A client that uploads a file can reasonably expect that all other clients will soon become aware of that file's existence.
Common web browsers typically permit javascript programs to communicate only with the server from which they were downloaded. Therefore, it may be necessary to download the javascript program, or at least a portion of it, from the HTTPCollab server.
==The Type-0 HTTPCollab Server->Client Interface==
In the simplest case, the Server exposes an interface that is simply HTTP/1.1, specifically GET, PUT, and DELETE. Some directory on the server (e.g. http://karmashare.sugarlabs.org/schools/GPA/group22/collabdir/) is selected as the "collaboration directory", and the server is configured to accept PUT and DELETE within this directory. To avoid interference by malicious actors PUTing gigabytes of data or DELETEing indiscriminately, it may be appropriate to employ an access control mechanism such as an HTTP cookie.
As far as a simple server is concerned, this describes its entire interaction with the client.
==The Type-0 JSCollab Client->Server Interface==
The server allows the client to upload arbitrary files, and every webapp can make use of this system as pleases its authors. However, a simple structure may provide a valuable scaffolding on which to build more complex systems. JSCollab describes one such simple client-side behavior.
A JSCollab client has a unique id during each session. This id may be a random string, and it need not be the same from session to session. The id must be a valid HTTP path name and must not contain the characters "_" or "/".
A message in JSCollab has a key, a value, and an index. The key is a string subject to the same constraints as the unique id. The value is a sequence of arbitrary bytes. The index is an integer indicating the number of messages previously sent by the user, incremented for each message, starting at 0.
To broadcast a message, a JSCollab client uploads a file with the name {unique id}_broadcast_{index}_{key}. The contents of the file are the value of the message. The index is represented as a base-10 string.
To send a message to a specific user specified by a target id, the client uploads a file with the name {unique id}_to_{target id}_{index}_{key}
For efficiency reasons, it may sometimes be appropriate to delete messages. A client may delete messages using the HTTP DELETE command. Because messages always have unique names, there is
==The Type-0 SugarHTTPCollab Server->Server Interface==
In the case of Sugar and Telepathy, the server runs on localhost, and acts as an interface to Telepathy. When the activity is initiated, the server is launched on any open port on localhost, and the browser is pointed at a known url on the host (e.g. http://localhost:42141/index.html) from which to download the first page. The javascript is already aware of the collaboration directory URL (e.g. http://localhost:42141/collabdir/).
The server is configured to accept all PUT and DELETE requests in collabdir/. If the activity is already shared, the PUT or DELETE request is immediately also transmitted to all other collaborating server instances.
When a new server joins, it must be informed of the current state of collabdir/. This is easy to do in a simple way; just pick a random participant upon joining and ask for the complete contents. Performing this update in a reliable and efficient manner is nontrivial, but should be possible. A sophisticated implementation is probably not necessary for a first release.