Karma/Collaboration: Difference between revisions

Latest revision as of 12:07, 3 August 2009

Objective

To provide a mechanism to enable collaboration using JavaScript. On this way, we'll be able to support collaboration on Karma lessons.

Use cases

Examples:

A simple chat (over an html file), where you can see connected children to the activity and talk each other.

Let's imagine a lesson: "Learning basic arithmetic", on this lesson we touch the topics: add, rest and multiply a number. At the end of the lesson we got the "Test". Here on "Test" one child writes a basic equation and challenges other child to solve it, then switch turns.

The problem

How to create an easy way to write collaborative JavaScript to be run client-side in browsers.

Keep in mind

JavaScript has no model for distributed collaboration.
Shared data can be considered volatile.

Possible solutions

It would be ideally as simple as possible and as web-like as possible.

lucian has suggested 2 possible ways[1]:

Starting local servers in each Browse and using XMLHttpRequest(XHR) to send data between.
Adding an API for this in window.sugar and using the existing Sugar collaboration Python API as a backend.

bemasc

a DNS server and httpd server on each client. (example WikiBrowse )

m_stone:

name the people with one wishes to collaborate with using:
- Telepathy
- DNS
- D-Bus to telepathy

a way to get those names to the JS.
- D-Bus to telepathy
- HTTP to a webserver to D-Bus to telepathy

data transfer via:
- D-Bus + Telepathy
- a central relay webserver
- point-to-point HTTP links to peer webservers.

Collaboration data:

Bemasc has suggested to store the messages using files and directories

/users could be a list of current users
/$USERNAME/ could be a list of messages, displayed as files
To check for new messages, just poll the contents of /$USERNAME/.
To check for new users, just poll /users.
If you want to see what messages $USERNAME has emitted, poll /$USERNAME/

Also one other way is using http PUT & GET

Flaws: it's all broadcast, and it's all polling.

Broadcast is inefficient in the network if you really only want to send a message to a single user. Polling wastes CPU, battery, and possibly network.

On way to handle polling is setting a high timeout for XHR. (Thanks Lucian)

@@ Line 1: / Line 1: @@
-<noinclude>{{GoogleTrans-en}}{{TOCleft}}</noinclude>
+<noinclude>{{GoogleTrans-en}}{{TOCright}}</noinclude>
 == Objective ==
 To provide a mechanism to enable collaboration using JavaScript. On this way, we'll be able to support collaboration on Karma lessons.
-== Examples ==
+== Use cases ==
+Examples:
 * A simple chat (over an html file), where you can see connected children to the activity and talk each other.
@@ Line 25: / Line 26: @@
 bemasc
-* a DNS server and httpd server on each client. WikiBrowse
+* a DNS server and httpd server on each client. (example WikiBrowse )
 m_stone:
-*name the people with one wishes to collaborate with:
+* name the people with one wishes to collaborate with using:
+** Telepathy
+** DNS
+** D-Bus to telepathy
+* a way to get those names to the JS.
 ** D-Bus to telepathy
 ** HTTP to a webserver to D-Bus to telepathy
@@ Line 38: / Line 44: @@
 ** point-to-point HTTP links to peer webservers.
-work in progress
+Collaboration data:
+Bemasc has suggested to store the messages using files and directories
+* /users could be a list of current users
+* /$USERNAME/ could be a list of messages, displayed as files
+* To check for new messages, just poll the contents of /$USERNAME/.
+* To check for new users, just poll /users.
+* If you want to see what messages $USERNAME has emitted, poll /$USERNAME/
+Also one other way is using http PUT & GET
+Flaws: it's all broadcast, and it's all polling.
+Broadcast is inefficient in the network if you really only want to send a message to a single user.  Polling wastes CPU, battery, and possibly network.
+On way to handle polling is setting a high timeout for XHR. (Thanks Lucian)
 [[Category:GSoC]]
+[[Category:Collaboration]]