SimultaneousEditing
Simultaneous editing is part of Topsoil.
We want people to be able to edit a web page simultaneously. Two major problems with simultaneous editing are conflict resolution and content divergence. What we want is that users should be able to see other users editing the same document in real time. This can be accomplished using an architecture where clients poll the server for changes and incorporate those changes in the current document as they come in. Imagine two users editing a single document. The first user could be editing the first paragraph and the second user could be making changes to the second paragraph. Each user will see the other user's changes as they are being made. If both users happen to edit the same thing, a conflict resolution facility could be provided, using which the users could either come up with a collaborative edit or all users could back off allowing only one user to make the change.
A simple editing scenario
User A, B and C are editing the document, "The quick brown fox jumps over the lazy dog".
1. User A makes an edit by changing 'quick' to 'QUICK'.
Edits are sent to the server in batches. A time-out makes sure that the edits are sent to the server even if a complete batch is not ready. A similar mechanism is used on the server side. Clients receive edits in batches or when there is a time-out on the server.
2. User A sends the edit to the server.
3. Server makes the edit available to other users.
4. User B and C receive the edit which gets incorporated in their editing panes.
Primary concerns in this architecture are those of excessive requests hitting the server simultaneously and the response times involved. Slow response times can have a possibly have a bad effect on the user experience.
- what is an edit
an edit involves, an addition, modification, or deletion in a document.
- what sort of overhead is associated with sending the edits to servers?
we don't want to incur any overhead when sending edits to the server. do avoid overheads, we will bunch together several edits and send them to the server in a batch. of course, with less frequent edits, we will send the edits to the server any way after a some time-out period. the number of edits to be bundled together should be such that there is a balance between edit update latency and the size of edit batch.
- what involves sending an edit to the server?
we will have to come up with a scheme for sending edits to the server. what exactly do we report?
- how are batches made and why?
we just bunch together edits. maybe append them one after another. the why has been answered above.
- how does a time-out operate?
we start a timer when we start creating a new batch. whatever happens first, completion of a batch or the time-out, will cause the data to be made available
- how does the server make edits available to other users?
this is an interesting question. we could have a bucket of sorts for each user on the server and each user request could retrieve the edits from that bucket. if a client goes offline, we will still have to keep the bucket for a specific period of time, in case, the client comes back up online again.
- what edits are sent to the client? all edits since the last time a particular client requested edits, or the current edits on the server only? note that if only the current edits are sent, a client * could potentially miss out on edits if it gets disconnected in between.
all the edits the client dint receive. if a client stays offline for greater than some period of time, its bucket is deleted. also, on the client side, a similar timer will expire and on going online will make the client fetch the most updated data from the server + any changes that are being made to the document currently
- look up comet?
