search

opencoweb / coweb

Open Cooperative Web Framework
Other
232 stars 29 forks source link

Need plugin points for Custom/Domain operation #178

Open AliceZhang opened 12 years ago

AliceZhang commented 12 years ago

Statement: When one user action involves multiple model updates in the form of supported operations (add, delete and update), we need to send the model change operations in one sync events, ie, the change need to be atomic

Example for illustration: Using the move operation in your cotree example A move operation contains 2 model update operations (delete and add) and 2 sync events are sent out. It seems to me that this may cause problem Say in the tree there are nodes with id 70. 80 and 90 as siblings. A node with id 801 is the child of node 80

on client 1, user move node 801 to be child of node 90 on client 2, user move node 801 to be child of node 70

Operations sent by client 1: op1: delete, topic: change.80

op2: insert, topic: change.90

Operations sent by client 2 opx: delete, topic: change.80 opy: insert, topic: change.70

client 1 update its model (add 801 as child of 90) before receives 2 sync events from client 2 When transform opx against op1, null is returned.. When transform opy against op1, because keys are not the same, it returns opy so on client 1, node 801 end up being the child of node 70

on client 2, node 801 end up being the child of node 90

out of sync

There are applications with user actions that are more complicated than the move operation illustrated in your cotree example.

One possible solution: Besides the default operations provided by opencoweb: add, delete and update, coweb framework could add another operation, Custom/DomainOperation, and then ask application client to provide a domain specific handler to be used by each transformWith method that involes DomainOperation. It would then up to the application decide how to transform an domain operation

AliceZhang commented 12 years ago

Would anyone comment on if there is a problem with the move action in cotree example?

Brian-Burns-Bose commented 12 years ago

I can see where there can be issues with this scenario. Here is are the problems.

  1. The clients send their sync events after they have updated their models. This makes it difficult to reverse any actions.
  2. Because we are using two primitive operations for a "move", delete followed by insert, the potential is there for the OT engine to pick 2 different winners for each operation. Ideally you would want the op engine to pick the same winning client for both operations.

Although creating a custom operation for the OT engine is possible (see FAQ 1.13 http://cooffice.ntu.edu.sg/otfaq/), this can add a lot of complexity. Perhaps we could make use of the moderator for this situation. The moderator can act as a neutral party since it doesn't have a UI it will never be initiating these types of move events. In the scenario mentioned above, the moderator will receive the 2 delete events and the OT engine will pick a winner. The moderator can then send out it's own sync event say {type: null, topic: mod.delete.change.80,....}. The clients only update their models when they receive this sync event with the mod prefix on the topic. The operation type null is used so that this sync event does not go through the OT engine again. It doesn't have to because it came from the moderator.