I am trying to understand the collab guide. I am also writing this post in the hope the the guide can be made clearer:
Authority.doc is defined and modified but never used. Is that meant for a more elaborate example where the server needs the document ? or is something missing from the client example where it can ask for the document ? can this be made clearer ?
Authority.stepClientIDs is sent back to the client in stepsSince ‘which is a way for them to later recognize which changes came from them’ but is never used - how and why would the client use this information ? can the example be extended to show this ?
in the client dispatchTransaction function how does concurrency works ? that is if on authority.receiveSteps the authority determines that someone else has already pushed changes and the current changes cannot be applied how and where does the client get notified and handle this ? can that be made clearer ?
Hi, thanks for the feedback. I’ll keep it in mind the next time I work on the guides (they’ll need a lot of cleaning up and smoothing out before I publish 1.0). Here are some short answers in the meantime:
Authority.doc is defined and modified but never used.
The idea is that it can be valuable for the authority to have a version of the document, both for saving it (if it’s the server) and for validating that the steps sent by clients actually make sense.
Authority.stepClientIDs is sent back to the client in stepsSince […] but is never used
It is passed to receiveTransaction which needs it to know which steps are already known locally, and only need to be confirmed (removed from the unsent step list) and which steps are new, coming from other users.
if on authority.receiveSteps the authority determines that someone else has already pushed changes and the current changes cannot be applied how and where does the client get notified and handle this ?
When a client’s steps go through, they are received by that client (via onNewSteps and the call to stepsSince), and because they have the client’s id associated with them, they’ll be removed from the list of pending steps. If they don’t go through (which can’t happen in the synchronous example code, but could happen as soon as you add some kind of network) they don’t get confirmed, so they stay around in the list of unsent steps and the client has to try sending them again later. In the example code, that’d happen after the conflicting changes were received (there have to be conflicting changes, or the authority would have accepted the steps), which will trigger a transaction, which will in turn call dispatchTransaction, which will re-send the steps (after rebasing them over the newly received steps).
where can I find the relevant client code that does the collaboration for the collab sample ? I tried to follow bundle_collab.js that is used in the sample but there is too much extra code …