User:Dash1291/Thoughts

This is my brainstorming/thoughts page.

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.

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.