18
edits
Changes
Jump to navigation
Jump to search
Line 12:
Line 12: − + + + + − + Line 24:
Line 27: − + − + − + Line 36:
Line 39: + + + + + + + + + + + + + + + + + + + + + + + +
no edit summary
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.
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 broadcast_{unique id}_{index}_{key}. The contents of the file are the value of the message. The index is represented as a base-10 string.
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_{target id}_{unique id}_{index}_{key}
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/).
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.