User:Dash1291/Thoughts

This is my brainstorming/thoughts page.

Realtime Collaboration on Visual Editor

Server's Data Model

When a new client initiates an editing session, the server would send a copy of its revision of the document. The server would use the VE modules for transaction processing that is applying transactions to its document model. This would be done by building node.js adapters for the modules and then using them.

Working with the Parser

When a fresh editing session is initiated by client on a new document through the collaboration server, the server would require the requested page to be parsed into its type of data model either DOM or linear model. This could be done in two ways -

Talking to the node.js parser in a client/server fashion

As the new parser is built on node.js, the collaboration server could use its API to request parsed content. This would mean, less heavylifting by the collaboration server, but increased dependence on HTTP communication between parser and collaboration server could lead to performance drop.

Integrating the parser with collaboration server

This would mean that collaboration server would use the parser modules directly to parse the desired content into its data model and serve it to clients.

Operational Transformation

This is the concurrency control model that should be used to consolidate concurrent operations emerging from different editors/clients and avoid conflicts. The transformation should work in the following way -

1. A new transaction on the client is pushed into its buffer, and composed with its compose-compatible transactions.
2. A transaction is sent to the server only after it receives an acknowledgment from the server.
3. The transaction received by the server is xformed against the copy of the server's transaction and then the transform of client's transaction is broadcasted to the other clients connected while sending an acknowledgment to the client that it received the transaction from.
4. The server keeps the latest revision of the document model and its transaction.

• Did a bit of more research over how OT would work. Transaction history on the server, and client-side transformation of buffered transactions against the transactions received from the server should also be incorporated in the above plan.

• Trevor indicated that the 'insert' and 'delete' operations would be replaced by one single 'replace' which should be easier to compose. Given that, they will all be of single type, calculating OT will include fewer pre-processing conditions.

Preserving undo behaviour

Currently, in favor of sensible undo behaviour, the transactions are polled and collapsed into one when cursor position in the editor UI is not changed while making changes to the text. If polling is not incorporated while sending transactions to the server, the server's document might not converge to state of the document on the client's editor. Therefore, information of polling start/finish should be attached to the transactions emitted from the client. The server keeps track of polling start/finish of every client and accordingly may collapse transactions on the server side thus trying to mimic the behaviour similar to the client. This way, current undo behaviour will be preserved while keeping it consistent over the distributed system.

Data Flow

This is the proposed data flow from the collaboration server.

At the client, the serialized HTML through an intermediate HTML DOM would be converted to Linear Model with the help of recently developed DOM->LinearModel convertor. This linear model would be used to synthesize client's document model.