opencoweb / coweb

Open Cooperative Web Framework

Open Cooperative Web Framework

** This project is no longer maintained and provided as is. **

Homepage

https://github.com/opencoweb/coweb/wiki

Project page

http://dojofoundation.org/projects/opencoweb

Code

https://github.com/opencoweb/coweb

Documentation

http://opencoweb.org/ocwdocs

User group

https://groups.google.com/group/opencoweb

Dev group

https://groups.google.com/group/opencoweb-dev

IRC

#coweb on irc.freenode.net

What is it?

The Open Cooperative Web Framework enables the creation of cooperative web applications featuring concurrent real-time interactions among remote users and external data sources. The framework handles remote notification of user changes, the resolution of conflicting changes, and convergence of application state with minimal information from the application.

The current implementation of the framework is based on open web technologies such as AMD, Bayeux, and WebSockets. The framework includes:

• A JavaScript API for sending and receiving coweb events
• An JavaScript operation engine using operational transformation to ensure shared state convergence
• A Python coweb server built on the Tornado web framework
• A Java coweb server built on the CometD Java library
• API documentation, tutorials, and examples

Getting Started

Read the the framework documentation online at http://opencoweb.org/ocwdocs. It includes tutorials on how to obtain the coweb package from Maven Central or PyPI and write your first cooperative web application.

Send mail to the coweb users group or join us on IRC if you're having trouble.

Developer setup

For developers seeking to develop this project directly, see https://github.com/opencoweb/coweb/wiki/Developer-Setup.

Status

Tagged revisions in the master branch are our stable releases. The docs at http://opencoweb.org/ocwdocs match the latest stable release.

The opencoweb/coweb/master branch on GitHub contains the framework code progressing toward the next stable release. We increment the version number in the code immediately after tagging a stable release so it reflects our next intended stable version.

The opencoweb/cowebx/master branch on GitHub contains example applications and widgets using the framework. We do not plan to make stable releases of the examples. Instead we will attempt to keep them working with all versions of the framework version 0.4 or higher.

All APIs are subject to change until we hit a v1.0 milestone.

Support

Currently, the JavaScript portions of the coweb framework should work in the following browsers.

• Firefox 3.5+
• Safari 4+
• Chrome
• IE8+
• Opera 10.50+
• Mobile Safari on iOS 4+
• Android Browser 1.6+

For our Java coweb server, we support any environment that can run a Java Servlet 3.0 compliant container (e.g., Jetty, Tomcat). For the Python server, we support any environment where Tornado can operate.

Please report an issue on GitHub if you have trouble in one of these browsers or server environments.

License

Copyright (c) The Dojo Foundation 2011. All Rights Reserved.

Copyright (c) IBM Corporation 2008, 2011. All Rights Reserved.

See the LICENSE file for the terms of the OpenCoweb dual BSD/AFL license.

Packaged builds of the OpenCoweb JavaScript framework located in coweb/js/release include third-party code that is not covered under the OpenCoweb License. See the NOTICES file for details of these dependencies.

Contributing

The Open Cooperative Web Framework is a Dojo Foundation project, and as such follows the contribution directives of the Dojo Foundation. Please read them if you wish to contribute. If you agree to their terms, feel free to fork our code and send us pull requests on GitHub.

Credits

This open source project derives from a broader IBM cooperative web project. The initial IBM contribution includes efforts from the following people:

Bill Abt, Krishna Akella, Hisatoshi Adachi, David Boloker, Paul Bouchon, Brian Burns, Bryce Curtis, Andrew Donoho, Dan Gisolfi, Wing Lee, Peter Parente, Aaron Reed, Roger Que, Sonal Starr, Michael Stewart, Wayne Vicknair, Royce Walter, Peter Westerink

Additional contributions made to the project under the Dojo Foundation come from the following people:

Richard Backhouse, Nick Fitzgerald

References

The operational transformation algorithm used in the framework is based on various lines of research, such as:

• C. Sun, "Operational Transformation Frequently Asked Questions and Answers"
  2010. [Online]. Available: http://cooffice.ntu.edu.sg/otfaq/
• D. Sun and C. Sun: "Context-based Operational Transformation in Distributed Collaborative Editing Systems," in IEEE Transactions on Parallel and Distributed Systems, Vol. 20, No. 10, pp. 1454 – 1470, Oct. 2009.
• D. Sun and C. Sun, "Operation context and context-based operational transformation," in CSCW '06: Proceedings of the 2006 20th anniversary conference on Computer supported cooperative work. New York, NY, USA: ACM Press, 2006, pp. 279-288. [Online]. Available: http://dx.doi.org/10.1145/1180875.1180918
• D. Sun, S. Xia, C. Sun, and D. Chen, "Operational transformation for collaborative word processing," in CSCW '04: Proceedings of the 2004 ACM conference on Computer supported cooperative work. New York, NY, USA: ACM, 2004, pp. 437-446. [Online]. Available: http://dx.doi.org/10.1145/1031607.1031681
• S. Xia, D. Sun, C. Sun, D. Chen, and H. Shen, "Leveraging single-user applications for multi-user collaboration: the coword approach," in CSCW '04: Proceedings of the 2004 ACM conference on Computer supported cooperative work. New York, NY, USA: ACM, 2004, pp. 162-171. [Online]. Available: http://dx.doi.org/10.1145/1031607.1031635

coweb's Issues

[cowebx] Sample Admin UI and SessionManager API for Java Server

We need to create a default Admin UI for the Java Server

Rebase Servers to CometD GA v2.1

We will move to the official release of cometD not the release candidate.

Continuous integration

Run whatever tests we have available on push to github. Testswarm looks promising for JS, but it's UI needs a bit of tweaking to show results better. Also running jslint over the JS code will help flush out problems early.

JS API cleanup

Our current JS API exactly mimics the PBS API, rough spots and all, as our original goal was backward compatibility with PBS coweb apps. But I think we've agreed that OCW is upstream and projects using it should adapt as needed (e.g., for our AMD port). If this is true, then there are a few places in the JS API that should get cleaned up to remove legacy uses:

1. The word conference is used all over the API (subscribeConferenceStart, joinConference, updateInConference, ...). This is not ideal because nowhere in doc or current lingo do we refer to conferences. This is a history leftover. These methods should be truncated like subscribeStart, join, update, etc. The word conference is unneeded and makes the method names longer and more confusing.

2. In the CollabInterface (http://opencoweb.org/ocwdocs/js/collab.html), there's a mix of callbacks that receive one object argument as a parameter with properties hanging off of it (e.g., subscribeConferenceReady(info)) and other callbacks that receive individual parameters (e.g., subscribeSync(topic, value, type, pos, site)). Experience shows the prior is more extensible, especially for large #s of args, and the latter is more explicit but bad for large arg counts. Either way, we should stick with one or the other instead of a mix of both. The mix requires everyone to look at the doc for each method to see which form it follows.

Of course, we've already put 0.3 out and this might break some people. It will also require updates to any old coweb apps we have internally. But we declared ourselves unstable (by version and by note) until 1.0 so now is the time to do this, if ever.

There are probably other cases that should get a bath, but these are the glaring ones.

Bot Transport support tutorial/demo

Create a bot wrapper supporting JMS or MQTT or another protocol for bot to session communication.

This is a good learning exercise as well as good demo to have.

Support length in op engine

The op engine currently lacks the concept of "length" so operations on runs of text, arrays of items, etc. have to be sent individually. This causes performance problems in certain use cases.

We should not tackle this until we have more unit tests in place to avoid regressions.

Java Server Logging Architecture

We need some standard log info for OpenCoweb.

What is required outside of the web app server?
What is required from a cometd perspective?

Review op engine control algorithm

http://www3.ntu.edu.sg/home/czsun/projects/otfaq/ has been updated with more information about the "false-tie" problem and how to guarantee convergence when it occurs. I need to work through it and check our op engine control algorithm against the cases it describes. We've had problems around the "false-tie" case in the past, so a review of our code is in order.

Demos need an index.html

Need a top-level index.html file with simple links to the demos underneath. Eases user discovery of the demos and guarantees the URLs are the same to avoid users joining different sessions by accident.

Enablement of Java Server Extensions

Provide support for enabling Java extension points.

Support for reconnection when long-polling sessions cause disconnects

When dragging the map in the comap demo, Mobile Safari appears to fail to reconnect its long polling XHR to the server and, as a result, gets a disconnected from session message.

1. Happens if the iOS device is doing the continuous sync while dragging.
2. Doesn't happen if a desktop machine is doing the dragging and the iOS device is just receiving.

My guess is we're using up all the XHR connects Mobile Safari allows going to the coweb server and downloading Google Map tiles in the demo. Need to turn on debug messages from cometd to find the exact error we're hitting and see if we can avoid it and/or retry.

Also need to test if this happens in the amd branch where we're using native XHR instead of dojo.xhr.

Coweb Governance Switching

Enhance Coweb API to support the ability to govern which users can broadcast events. When this support is toggled off all users (default) are allowed to broadcast. Otherwise, specific users are granted broadcast ability. All users get to see all events.

Refactor to Async Module Definition (AMD)

Currently (v0.1) leverages the Dojo Core Modules (v1.5) for Class Declaration specs and a Class Loader. This dependency on the Core Modules raises two issues:

1. It bloats us and therefore impacts performance and size, especially when considering future mobile support.
2. Dojo has not put a stack in the ground on a loader and therefore we are kind of stuck. If a developer is using something other than Dojo Toolkit for UI controls, we now require them to bring in Dojo just for the loader.

Going forward, we feel there are two things we can do to reduce our footprint, increase our degree of flexibility (from the web developer perspective, and eliminate some dependencies:

1. Embrace the Asynchronous Module Definition API
2. Incorporate the use of RequireJS for test, tutorials, demos but ensure that it is abstracted out so that any loader can be used. Our compatibility with AMD will ensure this.

The AMD spec details are desc ribbed here: http://wiki.commonjs.org/wiki/Modules/AsynchronousDefinition

Dojo Toolkit 1.6 will have support for this spec, so we are keeping in step with the core toolkit.

This feature once implemented can be consider a pre-mobile performance feature.

CoList Demo

Create a Cooperative Web Shopping List demo to compliment tutorials.

Unit Test Suite Environment

Add dynamic unit testing using to the project build environment.

Different browsers in same session breaks sync on win 7

win7x64 java 1.6
Made sure I have the latest code.
Cleaned the coweb_example
run the coweb_example
open 2 tabs to the comap example in Firefox 4.0b10
send a test chat message
works fine
open the comap example in chrome (8.0.552.237)
try to send a chat message from chrome
fails. message in server: CollabDelegate::onSync remove bad client
while that (chrome) tab is open the firefox tabs can't send each other messages.
once i close the chrom tab the firefox tabs can again send messages to each other

also tested with the first 2 being in chrome, and then adding in a 3rd from firefox, same (problematic) behavior

C:\Users\tgm\Documents\dev\newcoweb\coweb>git pull
Already up-to-date.

C:\Users\tgm\Documents\dev\newcoweb\coweb>cd servers\java\coweb_example

C:\Users\tgm\Documents\dev\newcoweb\coweb\servers\java\coweb_example>mvn clean
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building OpenCoweb :: Java :: Examples 0.2
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ coweb_example ---
[INFO] Deleting C:\Users\tgm\Documents\dev\newcoweb\coweb\servers\java\coweb_exa
mple\target
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 17.019s
[INFO] Finished at: Wed Feb 02 08:38:21 EST 2011
[INFO] Final Memory: 3M/91M
[INFO] ------------------------------------------------------------------------
C:\Users\tgm\Documents\dev\newcoweb\coweb\servers\java\coweb_example>mvn jetty:r
un-war
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building OpenCoweb :: Java :: Examples 0.2
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] >>> jetty-maven-plugin:7.1.5.v20100705:run-war (default-cli) @ coweb_exam
ple >>>
[INFO]
[INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @ coweb_ex
ample ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory C:\Users\tgm\Documents\dev\newcoweb\c
oweb\servers\java\coweb_example\src\main\resources
[INFO]
[INFO] --- maven-compiler-plugin:2.3.1:compile (default-compile) @ coweb_example
 ---
[INFO] Compiling 1 source file to C:\Users\tgm\Documents\dev\newcoweb\coweb\serv
ers\java\coweb_example\target\classes
[INFO]
[INFO] --- maven-antrun-plugin:1.3:run (default) @ coweb_example ---
[INFO] Executing tasks
     [copy] Copying 33 files to C:\Users\tgm\Documents\dev\newcoweb\coweb\server
s\java\coweb_example\target\coweb_example\js\libs
     [copy] Copying 11 files to C:\Users\tgm\Documents\dev\newcoweb\coweb\server
s\java\coweb_example\target\coweb_example\comap
     [copy] Copying 4 files to C:\Users\tgm\Documents\dev\newcoweb\coweb\servers
\java\coweb_example\target\coweb_example\colist
[INFO] Executed tasks
[INFO]
[INFO] --- maven-resources-plugin:2.4.3:testResources (default-testResources) @
coweb_example ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory C:\Users\tgm\Documents\dev\newcoweb\c
oweb\servers\java\coweb_example\src\test\resources
[INFO]
[INFO] --- maven-compiler-plugin:2.3.1:testCompile (default-testCompile) @ coweb
_example ---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-surefire-plugin:2.5:test (default-test) @ coweb_example ---
[INFO] No tests to run.
[INFO]
[INFO] --- maven-war-plugin:2.1-beta-1:war (default-war) @ coweb_example ---
[INFO] Packaging webapp
[INFO] Assembling webapp[coweb_example] in [C:\Users\tgm\Documents\dev\newcoweb\
coweb\servers\java\coweb_example\target\coweb_example]
[INFO] Processing war project
[INFO] Copying webapp resources[C:\Users\tgm\Documents\dev\newcoweb\coweb\server
s\java\coweb_example\src\main\webapp]
[INFO] Processing overlay[ id org.cometd.javascript:cometd-javascript-dojo]
[INFO] Webapp assembled in [34620 msecs]
[INFO] Building war: C:\Users\tgm\Documents\dev\newcoweb\coweb\servers\java\cowe
b_example\target\coweb_example.war
[INFO]
[INFO] <<< jetty-maven-plugin:7.1.5.v20100705:run-war (default-cli) @ coweb_exam
ple <<<
[INFO]
[INFO] --- jetty-maven-plugin:7.1.5.v20100705:run-war (default-cli) @ coweb_exam
ple ---
[INFO] Configuring Jetty for project: OpenCoweb :: Java :: Examples
[INFO] Context path = /coweb_example
[INFO] Tmp directory = C:\Users\tgm\Documents\dev\newcoweb\coweb\servers\java\co
web_example\target\tmp
[INFO] Web defaults = org/eclipse/jetty/webapp/webdefault.xml
[INFO] Web overrides =  none
[INFO] Starting jetty 7.1.5.v20100705 ...
2011-02-02 08:39:40.380:INFO::jetty-7.1.5.v20100705
2011-02-02 08:39:40.735:INFO::Extract jar:file:/C:/Users/tgm/Documents/dev/newco
web/coweb/servers/java/coweb_example/target/coweb_example.war!/ to C:\Users\tgm\
Documents\dev\newcoweb\coweb\servers\java\coweb_example\target\coweb_example
2011-02-02 08:39:48.667:INFO::No Transaction manager found - if your webapp requ
ires one, please configure one.
CowebSecurityPolicy::canHandshake
{"id":"1","channel":"/meta/handshake"}
null
2011-02-02 08:39:49.222:INFO::Started [email protected]:8080
[INFO] Started Jetty Server
[INFO] Starting scanner at interval of 1 seconds.
CowebSecurityPolicy::canHandshake
{"id":"1","minimumVersion":"0.9","supportedConnectionTypes":["long-polling","cal
lback-polling"],"advice":{"interval":0,"timeout":60000},"channel":"/meta/handsha
ke","ext":{"ack":true,"coweb":{"sessionid":"2af4a49ff6ea56875502983995c5fcdc"}},
"version":"1.0"}
2af4a49ff6ea56875502983995c5fcdc
2011-02-02 08:40:35.681:INFO::Enabled message acknowledgement for client 2sqemoj
wksyjq7zpv5nnfxwko
SessionHandler::onUnsubscribe
/service/session/join/*
CowebSecurityPolicy::canHandshake
{"id":"1","minimumVersion":"0.9","supportedConnectionTypes":["long-polling","cal
lback-polling"],"advice":{"interval":0,"timeout":60000},"channel":"/meta/handsha
ke","ext":{"ack":true,"coweb":{"sessionid":"2af4a49ff6ea56875502983995c5fcdc"}},
"version":"1.0"}
2af4a49ff6ea56875502983995c5fcdc
2011-02-02 08:40:44.455:INFO::Enabled message acknowledgement for client 3b5225g
pzwtg3143lmjq60l9ps
SessionManager::handleMessage
SessionHandler::onUnsubscribe
/service/session/join/*
CowebSecurityPolicy::canHandshake
{"id":"1","minimumVersion":"0.9","supportedConnectionTypes":["long-polling","cal
lback-polling"],"advice":{"interval":0,"timeout":60000},"channel":"/meta/handsha
ke","ext":{"ack":true,"coweb":{"sessionid":"fc79c28ae65bdd59894082c712bbbfdf"}},
"version":"1.0"}
fc79c28ae65bdd59894082c712bbbfdf
2011-02-02 08:41:03.235:INFO::Enabled message acknowledgement for client 4enk3oo
0wdxkn178jixb0ml37e
SessionHandler::onUnsubscribe
/service/session/join/*
CollabDelegate::onSync remove bad client
CollabDelegate::onSync remove bad client
CollabDelegate::onSync remove bad client
CollabDelegate::onSync remove bad client
CollabDelegate::onSync remove bad client
CollabDelegate::onSync remove bad client
CollabDelegate::onSync remove bad client

C:\Users\tgm>java -version
java version "1.6.0_21"
Java(TM) SE Runtime Environment (build 1.6.0_21-b07)
Java HotSpot(TM) 64-Bit Server VM (build 17.0-b17, mixed mode)

Abstract ops when history buffer deserialized

Noticed a possible bug while converting the op engine to AMD format. The HistoryBuffer.setState method creates base Operation objects instead of subclasses of the proper type. I'm surprised we never see an exception considering the base methods throw abstract errors when used, so maybe this is a dead code path. Need to investigate.

Dojo build profile

Commit a build profile to help in producing a coweb Dojo layer.

Update Docs for Optional Java Admin Support

Docs should explicitly state that our two servers are not feature equivalent.

Java Server Maven Build Scripts

Add Mavin Build support to compliment existing Ant scripts for Java Sever.

JavaScript API and API documentation

Initial Cooperative Web API to enable cooperative web concepts in web application development.

This code drop will include JavaScript API docs as well.

node.js coweb server implementation

Dylan mentioned this in one of our initial talks. I think he said the cometd guys were interested in doing a node.js implementation of a cometd server. If they build it, someone could easily build a coweb implementation on top of their work.

I don't think we want to maintain yet another server impl, but if someone steps up to do the work and takes ownership of the node.js server, we should back that. node.js is a hot-topic right now and having node.js coweb server would expand interest in coweb.

Mobile UI Versions of Colist and CoMap Demos

CoMap Demo

A basic cooperative web demonstration application whereby multiple users can interact with a Google Map. This demonstration allows users to quickly grasp the concept of operational transformation for conflicting user interactions.

Include stable JS builds in releases

Most JS projects release minified, single file copies of libraries for stable releases. To name a few:

• Dojo
• cometd
• jQuery
• RequireJS

We're odd in that we provide the raw source and have scripts people have to run to grab JS dependencies (OpenAjax, cometd), setup a JS build environment (node.js, Rhino, Google Closure, etc.), and then run the build to minify our code. Big hurdle for adoption.

A simple answer would be to do the build of the core coweb code into a coweb.js upon each stable release. We could commit them right into a folder in the repo (e.g., www/libs/build/coweb-0.5.min.js) and then tag the release. Anyone that grabs the stable download will have them. Anyone that clones will have the current raw source plus all the old stable version if they want to use them (e.g., regression testing).

This also simplifies our server setup. People won't have to run scripts to go fetch OAA Hub and cometd anymore. They're baked into the built copy of coweb.js. The downside is now we have other deps in our repo, but they're license friendly and people understand these are builds, not source.

Update Readme.rst with Dojo Foundation page link after launch

JavaScript Abstract Coweb Class Interface for UI Controls/Widgets

In order to help kickstart a web developers coweb-enablement of a UI Widget or UI control from any framework, we want to provide an abstract interface file.

Developers should feel encouraged to coweb enable Silverlight, Actionscript, Dojo, and any other JavaScript UI library. This interface file will provide the web developer with a basic skeleton for extending the base UI library component with coweb capability.

This file is not required when using our framework but it should serve as a reusable template for developers.

Java Server

Initial code drop for a Java Server that works with the JavaScript API.
This code drop will include:

1. Java Installation Steps
2. Ant Build Scripts

Code repository separation of demos and extensions

We currently have everything located in one github repro. The fact that BusyDialog (which uses Dojo) is inappropriately include din the core. The argument then follows that the demos are also contained in the core -- why not create three separations:
(1) coweb: core framework
(2) apps: Demonstrations and other solution applications
(3) widgets: Extension like the BusyDialiog implemented in Dojo

Post releases to Maven Central, PyPI

We should get the ocw Java portions into the central maven repository so anyone can pull it down as a dependency without having to get it from github (e.g., pbs).

Sonatype is open to all OSS projects and syncs with the central repo. Getting in here should be easy.

http://nexus.sonatype.org/oss-repository-hosting.html

We should also post the Python server + stable JS bundle to the Python Package Index.

http://pypi.python.org/pypi

I've done the latter before, and the former has plenty of instructions.

Dojo Socket I/O Wire Protocol

Integrate DojoX Socket I/O Wire Protocol support as suggested by Dylan Schiemann of SitePen.

Consolidate version numbers in pom.xmls

Define a property. Figure out archetype.

Support concept of updater "class" for late-join

Scenarios:

User 1 using desktop
User 2 using mobile device
User 3 using limited interface

Say user #4 joins on a mobile device. Right now, the coweb server picks any user (1,2,3) not busy updating someone else to be the updater. Which user is ideal to update the joiner is app specific though:
#1 is ideal if the mobile data is the same as the desktop data
#2 is ideal if the data in the mobile interface is different than the desktop data

The concept of a class of updater controlled by the application would allow this. The class could be sent during the announcement of a new updater.

User #1: desktop
User #2: mobile
User #3: limited
User #4: mobile

The server could then pair up the best updater for a joiner. The pairing could be done based on prioritization along multiple dimensions as well. For example:

User #1: doctor.desktop
User #2: doctor.mobile
User #3: patient
User #4: doctor.mobile

The server could look for exact matches for doctor.mobile first and then fall back on doctor.desktop if no mobile doc is found. Maybe it falls back to patient or maybe not depending on what rules we decide.

typo in docs/tutorial/install.rst

there's no 's' at the end of servers/java/coweb_example
the docs have several instances that expect this.

Update ReadMe with DF Copyright

After DF announcement, update ReadMe License Section which currently reads:

License

Copyright (c) IBM Corporation 2008, 2011. All Rights Reserved.

See the LICENSE file for details.

Maven Plug-in Usage Instructions for Eclipse

As requested by IBM Rational, we should establish an Eclipse compliant plugin to allow the project to be dropped into an Eclipse based IDE.

Coweb server errors on Windows

see what happens when i mvn jetty:run-war and then try to hit the url in the browser (which is also part of the typos i logged on github, i needed to go to http://localhost:8080/coweb_example/comap/index.html )

C:\Users\tgm\Documents\dev\coweb\servers\java\coweb_example>mvn jetty:run-war
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building OpenCoweb :: Java :: Examples .1
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] >>> jetty-maven-plugin:7.1.5.v20100705:run-war (default-cli) @ coweb_exam
ple >>>
[INFO]
[INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @ coweb_ex
ample ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory C:\Users\tgm\Documents\dev\coweb\serv
ers\java\coweb_example\src\main\resources
[INFO]
[INFO] --- maven-compiler-plugin:2.3.1:compile (default-compile) @ coweb_example
 ---
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] --- maven-antrun-plugin:1.3:run (default) @ coweb_example ---
[INFO] Executing tasks
[INFO] Executed tasks
[INFO]
[INFO] --- maven-resources-plugin:2.4.3:testResources (default-testResources) @
coweb_example ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory C:\Users\tgm\Documents\dev\coweb\serv
ers\java\coweb_example\src\test\resources
[INFO]
[INFO] --- maven-compiler-plugin:2.3.1:testCompile (default-testCompile) @ coweb
_example ---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-surefire-plugin:2.5:test (default-test) @ coweb_example ---
[INFO] No tests to run.
[INFO]
[INFO] --- maven-war-plugin:2.1-beta-1:war (default-war) @ coweb_example ---
[INFO] Packaging webapp
[INFO] Assembling webapp[coweb_example] in [C:\Users\tgm\Documents\dev\coweb\ser
vers\java\coweb_example\target\coweb_example]
[INFO] Processing war project
[INFO] Copying webapp resources[C:\Users\tgm\Documents\dev\coweb\servers\java\co
web_example\src\main\webapp]
[INFO] Processing overlay[ id org.cometd.javascript:cometd-javascript-dojo]
[INFO] Webapp assembled in [3912 msecs]
[INFO] Building war: C:\Users\tgm\Documents\dev\coweb\servers\java\coweb_example
\target\coweb_example.war
[INFO]
[INFO] <<< jetty-maven-plugin:7.1.5.v20100705:run-war (default-cli) @ coweb_exam
ple <<<
[INFO]
[INFO] --- jetty-maven-plugin:7.1.5.v20100705:run-war (default-cli) @ coweb_exam
ple ---
[INFO] Configuring Jetty for project: OpenCoweb :: Java :: Examples
[INFO] Context path = /coweb_example
[INFO] Tmp directory = C:\Users\tgm\Documents\dev\coweb\servers\java\coweb_examp
le\target\tmp
[INFO] Web defaults = org/eclipse/jetty/webapp/webdefault.xml
[INFO] Web overrides =  none
[INFO] Starting jetty 7.1.5.v20100705 ...
2011-01-21 00:12:05.914:INFO::jetty-7.1.5.v20100705
2011-01-21 00:12:05.937:INFO::Extract jar:file:/C:/Users/tgm/Documents/dev/coweb
/servers/java/coweb_example/target/coweb_example.war!/ to C:\Users\tgm\Documents
\dev\coweb\servers\java\coweb_example\target\coweb_example
2011-01-21 00:12:15.404:INFO::No Transaction manager found - if your webapp requ
ires one, please configure one.
java.io.IOException: The filename, directory name, or volume label syntax is inc
orrect
        at java.io.WinNTFileSystem.createFileExclusively(Native Method)
        at java.io.File.createNewFile(File.java:883)
        at org.coweb.CowebExtension.(CowebExtension.java:26)
        at org.coweb.servlet.AdminServlet.init(AdminServlet.java:76)
        at javax.servlet.GenericServlet.init(GenericServlet.java:241)
        at org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.jav
a:421)
        at org.eclipse.jetty.servlet.ServletHolder.doStart(ServletHolder.java:24
5)
        at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLife
Cycle.java:55)
        at org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.ja
va:691)
        at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletC
ontextHandler.java:204)
        at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.jav
a:994)
        at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandle
r.java:588)
        at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:380
)
        at org.mortbay.jetty.plugin.JettyWebAppContext.doStart(JettyWebAppContex
t.java:114)
        at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLife
Cycle.java:55)
        at org.eclipse.jetty.server.handler.HandlerCollection.doStart(HandlerCol
lection.java:165)
        at org.eclipse.jetty.server.handler.ContextHandlerCollection.doStart(Con
textHandlerCollection.java:162)
        at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLife
Cycle.java:55)
        at org.eclipse.jetty.server.handler.HandlerCollection.doStart(HandlerCol
lection.java:165)
        at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLife
Cycle.java:55)
        at org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrappe
r.java:92)
        at org.eclipse.jetty.server.Server.doStart(Server.java:242)
        at org.mortbay.jetty.plugin.JettyServer.doStart(JettyServer.java:67)
        at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLife
Cycle.java:55)
        at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMo
jo.java:437)
        at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.
java:377)
        at org.mortbay.jetty.plugin.JettyRunWarMojo.execute(JettyRunWarMojo.java
:68)
        at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(Default
BuildPluginManager.java:107)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor
.java:209)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor
.java:153)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor
.java:145)
        at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProje
ct(LifecycleModuleBuilder.java:84)
        at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProje
ct(LifecycleModuleBuilder.java:59)
        at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBu
ild(LifecycleStarter.java:183)
        at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(Lifecycl
eStarter.java:161)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
        at org.apache.maven.cli.MavenCli.execute(MavenCli.java:534)
        at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Laun
cher.java:290)
        at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.jav
a:230)
        at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(La
uncher.java:409)
        at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:
352)
CowebSecurityPolicy::canHandshake
{"id":"1","channel":"/meta/handshake"}
null
2011-01-21 00:12:15.710:INFO::Started [email protected]:8080
[INFO] Started Jetty Server
[INFO] Starting scanner at interval of 1 seconds.
CowebSecurityPolicy::canHandshake
{"id":"1","minimumVersion":"0.9","supportedConnectionTypes":["long-polling","cal
lback-polling"],"advice":{"interval":0,"timeout":60000},"channel":"/meta/handsha
ke","ext":{"ack":true,"coweb":{"sessionid":"aaac0546791823921350994515226a19"}},
"version":"1.0"}
aaac0546791823921350994515226a19
2011-01-21 00:12:21.149:INFO::Enabled message acknowledgement for client 2lhbe4s
6k4yzm1p82jpot1sosj
public void org.coweb.SessionManager.handleSubscribed(org.cometd.bayeux.server.S
erverSession,org.cometd.bayeux.Message): {"id":"5","subscription":"/service/sess
ion/join/*","channel":"/meta/subscribe","ext":{"coweb":{"sessionid":"aaac0546791
823921350994515226a19"}},"clientId":"2lhbe4s6k4yzm1p82jpot1sosj"}
java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.cometd.server.AbstractService.doInvoke(AbstractService.java:331)
        at org.cometd.server.AbstractService.invoke(AbstractService.java:293)
        at org.cometd.server.AbstractService.access$100(AbstractService.java:51)

        at org.cometd.server.AbstractService$1.onMessage(AbstractService.java:23
5)
        at org.cometd.server.BayeuxServerImpl.doPublish(BayeuxServerImpl.java:73
9)
        at org.cometd.server.BayeuxServerImpl.handle(BayeuxServerImpl.java:572)
        at org.cometd.server.transport.LongPollingTransport.handle(LongPollingTr
ansport.java:212)
        at org.cometd.server.CometdServlet.service(CometdServlet.java:152)
        at org.cometd.server.CometdServlet.service(CometdServlet.java:121)
        at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:527
)
        at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java
:423)
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.j
ava:119)
        at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.jav
a:493)
        at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandl
er.java:225)
        at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandl
er.java:930)
        at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:
358)
        at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandle
r.java:183)
        at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandle
r.java:866)
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.j
ava:117)
        at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(Cont
extHandlerCollection.java:245)
        at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerColl
ection.java:126)
        at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper
.java:113)
        at org.eclipse.jetty.server.Server.handle(Server.java:351)
        at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.
java:594)
        at org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpCo
nnection.java:1058)
        at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:764)
        at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:217)

        at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:42
4)
        at org.eclipse.jetty.io.nio.SelectChannelEndPoint.run(SelectChannelEndPo
int.java:489)
        at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool
.java:436)
        at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.NullPointerException
        at org.coweb.CowebExtension.send(CowebExtension.java:70)
        at org.cometd.server.BayeuxServerImpl.extendSend(BayeuxServerImpl.java:8
60)
        at org.cometd.server.ServerSessionImpl.deliver(ServerSessionImpl.java:17
7)
        at org.cometd.server.ServerSessionImpl.deliver(ServerSessionImpl.java:19
3)
        at org.coweb.CollabDelegate$BatchUpdateMessage.run(CollabDelegate.java:3
90)
        at org.cometd.server.ServerSessionImpl.batch(ServerSessionImpl.java:165)

        at org.coweb.CollabDelegate.onClientJoin(CollabDelegate.java:89)
        at org.coweb.SessionHandler.onSubscribe(SessionHandler.java:88)
        at org.coweb.SessionManager.handleSubscribed(SessionManager.java:192)
        ... 35 more

Host TestSwarm Results on Project Website

Optional Java Server Administration Support

Add optional session metadata persistence to our Java Server.

Java Demo Packaging

Delay receiving events from Java server

We see a 2-3s delay, sometimes, receiving events from the Java server, even when there are few clients and everyone is idle. For example, in comap:

1. Open three browser instances.
2. Send a chat message from one.
3. Message shows up almost instantly on one of the other two. Second one has 2-3 second delay.
4. Keep doing this for a while. Notice sometimes which browser gets the delay switches.

There are some config settings in cometd that we need to look at. Lazy delivery comes to mind, but it seems to be off by default.

This delay does not happen using the Python server.

Migration to RequireJS

Integrate RequireJS from Dojo Foundation.

Better disconnect handling

The Python Bayeux implementation has a fixed collection cycle for dead clients. It doesn't work well when a user leaves a page and an explicit disconnect message doesn't make it to the server (e.g., fast-back on Safari). There should be a shorter timeout for re-establishing the long-poll connection (like in the Java implementation).

Operation Engine Performance

In support for mobile applications, this feature needs to address performance improvements.

Python Server

Initial code drop for a Python Server that works with the JavaScript API.

Online Documentation

Use Github Pages to establish online access to framework documentation. Initial docs should include API, Server Installations, Architecture (op engine), and tutorials.

coweb_javascript module needs to be cleaned up.

The coweb_javascript module is pulling in all the dependent jars. We need to only bundle cometd js and coweb js. Dojo should be optional.

Feedback on op engine doc

Aaron did a review for me since he helped me with it long ago.

• In the "Convergence with operational transformation" section there is: OT determines if an operation performed by a remote user is “out-of-date” when it when the local user receives it because other operations
• In the same section, two paragraphs down, there is: The algorithm transforms the value of Bob’s update ( apple s oranges ) to account for the local update already made by Alice ( oranges apples ).
• Two paragraphs down from that is: The value of >the< operation is left as apples .
• In the section "Value adjustments", in the second paragraph: As described under , the engine notes the conflict between the two edits. What is ""? The chart/matrix?
• Three paragraphs down from that, there is: Cathy >'s< event carries no value only the position of the deleted item in the list.
• In the last paragraph of the section "Position adjustments", there is: Continuing this example, if Cathy decides to delete pears while Bob changes apples back to bananas , another position adjustment will be made when Cathy receives Bob’s event.
  This example doesn't have pears in it. The continuation of the example in the previous section had Cathy adding pears to the list. Rather than having the user look back five paragraphs, perhaps it would be better to reinforce that Cathy inserted pears at the beginning of this list before she then goes to delete it. Especially since the position of the pears item is so important.
• In the "Dropped events" section, in the second paragraph, there is: Prior update events have no effect on inbound delete events as noted above, so the... I assume 'as noted above' means as noted in the chart/matrix? I think that you should give the chart a tag/id so that you can refer to it directly and the user knows exactly where you are pointing. I found the chart useful, but I wasn't always sure when you were referring directly to it and when you weren't.

Filter op engine garbage collection events from bot

Putting a stake in the ground for now, but can revisit if bots need this info later. Filter op engine sync garbage collection events from going to bots to save some bits.

Revisit op engine garbage collection events

These use to be sent only when there were changes in the app. This was optimal. Then we started piggybacking a heartbeat on these in PBS so they're sent on a timer. This results in significantly more traffic.

I think we can go back to the smart approach because there's inherent heartbeats in comet with the long-poll reconnects. Need to investigate.