Real time Multi user CoWeb Editor

Coweb Editor Design Discussion

This page is intended to track our design discussions around a Coweb Editor as mentioned in issue 56.

Basic Requirements

• Plain-text, arbitrary length editing
• Persistence

Extended requirements

Get to these over time:

• Originator tracking (who wrote what)
• Some rich text functions (bold, italic)

Solution Preferences

• Minimal new server pre-reqs
• Minimal framework changes
• Minimal new requirements for apps (e.g., avoid extra API calls)
• Minimal new requirements for users (e.g., avoid save button)
• Don't try browser event tracking for editing (we tried this, it's horrendous)
• Don't lose data

Design Ideas

• Persistence: Node.js bot
• Persistence: State snapshots plus trailing log
• Arbitrary editing: Asynchronous op support
• No browser event tracking: Use modified version of Edit Distance algorithms (related)

Design Descriptions

Node.js bot (for persistence)

• Write a JS bot based on Node
• Launch the bot immediately on session start (1)
• Let the bot act as the initial updater if it has persisted state (1,2)
• If the bot has no state, send it state as if it's a late joiner (1,2)
• Bot receives sync messages like any other user
• Bot processes sync messages in JS op engine like any other user
• Bot applies messages to its copy of the shared state (3)
• Bot persists its updated state on its desired schedule

1. Requires framework changes
2. Requires protocol changes
3. Unknown if possible in general

State snapshots plus trailing log (for persistence)

• Launch bot immediately on session start (1)
• Let bot publish trailing log of ops if it persisted any from last session (1,2,3)
• Let the bot act as the initial updater if it has persisted state (1,2)
• Server requests or application pushes snapshot of state to bot on some interval (1, maybe 2)
• Bot tracks sync messages received since last state (4)
• Bot persists last state snapshot plus sync messages received until next snapshot

Alternatively, the server could perform these actions itself, without the bot (built-in vs bolt-on).

1. Requires framework changes
2. Requires protocol changes
3. Order here looks wrong, but it's right. Clients already cache ops received while waiting for state and replay AFTER applying state.
4. Sync messages will need cleanup before broadcasting back to clients next time (e.g., site IDs, context vectors). Can happen before persistence or before broadcast at start of next session.

Asynchronous op support (for arbitrary text edits)

• Application can "pause" op engine to prevent it from processing any incoming events (1,2)
• Application can allow any number of local edits while engine is paused (1)
• Application may continue sending ops while the engine is paused or not, but MUST send them before unpausing (3)
• Application can "resume" op engine to allow it to resume processing of incoming events, including those queued while paused

1. Requires JS framework changes
2. Requires server framework changes
3. New application requirement