Difference between revisions of "WebCollab"
| Line 12: | Line 12: | ||
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. | 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== | + | ==Type-0 Design== |
| + | The Type-0 design is the simplest useful implementation of this architecture. It does not provide a high degree of efficiency or security, but it permits the full range of desired client behaviors. | ||
| + | |||
| + | ===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. | 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. | As far as a simple server is concerned, this describes its entire interaction with the client. | ||
| − | ==The Type-0 JSCollab Client->Server Interface== | + | ===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. | 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. | ||
| Line 24: | Line 27: | ||
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. | 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 | + | 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 | + | 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, and are immutable, there is no risk of races between a client deleting a file and another client creating a file with the same name or updating the existing file. | 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, and are immutable, there is no risk of races between a client deleting a file and another client creating a file with the same name or updating the existing file. | ||
| − | ==The Type-0 SugarHTTPCollab Server->Server Interface== | + | ===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/). | 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/). | ||
| Line 36: | Line 39: | ||
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. | 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. | ||
| + | |||
| + | ==Refinements== | ||
| + | ===The Type-1 HTTPCollab Server->Client Interface=== | ||
| + | The Type-0 Server has two obvious deficits: efficiency and security. Efficiency is low, in the sense that if A sends a message to B, C will have to download the whole list of messages again to find out that the message is for someone else. Security is low, in the sense that any user can easily impersonate any other, or interfere with others' communications. | ||
| + | |||
| + | To enable greater efficiency, an obvious step is to introduce directories. Messages to one user may be segregated in a separate directory, so that users do not have to monitor each others messages. | ||
| + | |||
| + | To enable greater security, an obvious step is to employ access control permissions on these directories. | ||
| + | |||
| + | HTTP provides, or at least enables, some types of access control, but it does not provide any standard way for users to create directories. We could build such a system with POST messages, but a more standards-based approach is available through WebDAV. The WebDAV HTTP extensions include a MKCOL message type, allowing clients to make directories. WebDAV also provides a suitable access control mechanism for directories, in the form of Write Locking. | ||
| + | |||
| + | A Type-1 HTTPCollab Server provides a WebDAV interface, including at least GET, PUT, DELETE, and MKCOL. If security is desired, it should also provide LOCK and UNLOCK. | ||
| + | ===The Type-1 JSCollab Client->Server Interface=== | ||
| + | A Type-1 JSCollab client implements the same abstraction as a Type-0 client, but using directory structures and locking to improve efficiency and security. | ||
| + | |||
| + | The client first chooses a unique id, then uses the LOCK directive to acquire a depth:infinity write lock on the directory with that name. This lock will never be released. If high security is desired, it may be necessary to choose a random name to ensure that no other user could have locked it already. | ||
| + | |||
| + | The client then creates the directory with that name. Within that directory, the client creates two subdirectories: "broadcast/" and "to/". A broadcast message that would be "{unique id}_broadcast_{index}_{key}" in Type-0 becomes "{unique id}/broadcast/{index}_{key}" in Type-1. | ||
| + | |||
| + | If a user wishes to send a message to another user, the user must create a subdirectory of "to/" with the desired target id. Once created, such a directory should not be deleted. A directed message that would be "{unique id}_to_{target id}_{index}_{key}" in Type-0 is "{unique id}/to/{target id}/{index}_{key}" in Type-1. | ||
| + | |||
| + | A Type-1 client must monitor the root collaboration directory for the appearance of new users. When a new user appears, the client must monitor that user's broadcast/ directory for broadcast messages. The client must also monitor that user's to/ directory in case a message with the client's unique id should appear. If such a directory does appear, the client may stop polling to/, but must start polling to/{unique id}. | ||
| + | |||
| + | The large amount of polling required here represents a potential decrease in efficiency. To achieve high efficiency, the client must employ a form of "long polling" or similar push-like technique. It is not clear whether such behavior can work with a typical unmodified WebDAV server. | ||
Revision as of 13:21, 30 July 2009
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.
Type-0 Design
The Type-0 design is the simplest useful implementation of this architecture. It does not provide a high degree of efficiency or security, but it permits the full range of desired client behaviors.
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, and are immutable, there is no risk of races between a client deleting a file and another client creating a file with the same name or updating the existing file.
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.
Refinements
The Type-1 HTTPCollab Server->Client Interface
The Type-0 Server has two obvious deficits: efficiency and security. Efficiency is low, in the sense that if A sends a message to B, C will have to download the whole list of messages again to find out that the message is for someone else. Security is low, in the sense that any user can easily impersonate any other, or interfere with others' communications.
To enable greater efficiency, an obvious step is to introduce directories. Messages to one user may be segregated in a separate directory, so that users do not have to monitor each others messages.
To enable greater security, an obvious step is to employ access control permissions on these directories.
HTTP provides, or at least enables, some types of access control, but it does not provide any standard way for users to create directories. We could build such a system with POST messages, but a more standards-based approach is available through WebDAV. The WebDAV HTTP extensions include a MKCOL message type, allowing clients to make directories. WebDAV also provides a suitable access control mechanism for directories, in the form of Write Locking.
A Type-1 HTTPCollab Server provides a WebDAV interface, including at least GET, PUT, DELETE, and MKCOL. If security is desired, it should also provide LOCK and UNLOCK.
The Type-1 JSCollab Client->Server Interface
A Type-1 JSCollab client implements the same abstraction as a Type-0 client, but using directory structures and locking to improve efficiency and security.
The client first chooses a unique id, then uses the LOCK directive to acquire a depth:infinity write lock on the directory with that name. This lock will never be released. If high security is desired, it may be necessary to choose a random name to ensure that no other user could have locked it already.
The client then creates the directory with that name. Within that directory, the client creates two subdirectories: "broadcast/" and "to/". A broadcast message that would be "{unique id}_broadcast_{index}_{key}" in Type-0 becomes "{unique id}/broadcast/{index}_{key}" in Type-1.
If a user wishes to send a message to another user, the user must create a subdirectory of "to/" with the desired target id. Once created, such a directory should not be deleted. A directed message that would be "{unique id}_to_{target id}_{index}_{key}" in Type-0 is "{unique id}/to/{target id}/{index}_{key}" in Type-1.
A Type-1 client must monitor the root collaboration directory for the appearance of new users. When a new user appears, the client must monitor that user's broadcast/ directory for broadcast messages. The client must also monitor that user's to/ directory in case a message with the client's unique id should appear. If such a directory does appear, the client may stop polling to/, but must start polling to/{unique id}.
The large amount of polling required here represents a potential decrease in efficiency. To achieve high efficiency, the client must employ a form of "long polling" or similar push-like technique. It is not clear whether such behavior can work with a typical unmodified WebDAV server.