Content
View differences
Updated by Wieland Lindenthal 7 months ago
* In admin settings there is a global setting "Real time text collaboration" _on/off_. That is actually independent of the fact if there is a Hocuspocus server successfully set up or not.
* When the setting is _on_ BlockNote can expect Hocuspocus to be set up completely. If something is broken, it should throw errors. It does not fall back gracefully to the following case:
* When that setting is _off_:
* BlockNote based documents can be created and edited
* \[Note: This one was heavily questioned by @parimal. He argues that this tries to be some sort of small real-time editing but failing all the cues that a user needs. Users would not understand where changes, that they save are coming from if there are no live cursors for example\] Editing conflicts (race conditions) get resolved (on client side and not on server side)
* When starting to edit a document, the document has a last modified timestamp
* On saving a document the client tries to send the document to the back end and also provides the last modified timestamp
* If on the server side the **last modified** time stamp match, it means that it is safe to save the document
* If they don't match, the client loads the latest state from the server (and remembers the new **last modified** date) and merges it with the local document. It also informs the user that there were changes upstream and they are getting merged.
* If the user chooses to press "Save" again, then the merged document get pushed with the **last modified** timestamp.
* The server might or might not accept the document, based on the **last modified** timestamp
<br>
* When the setting is _on_ BlockNote can expect Hocuspocus to be set up completely. If something is broken, it should throw errors. It does not fall back gracefully to the following case:
* When that setting is _off_:
* BlockNote based documents can be created and edited
* \[Note: This one was heavily questioned by @parimal. He argues that this tries to be some sort of small real-time editing but failing all the cues that a user needs. Users would not understand where changes, that they save are coming from if there are no live cursors for example\] Editing conflicts (race conditions) get resolved (on client side and not on server side)
* When starting to edit a document, the document has a last modified timestamp
* On saving a document the client tries to send the document to the back end and also provides the last modified timestamp
* If on the server side the **last modified** time stamp match, it means that it is safe to save the document
* If they don't match, the client loads the latest state from the server (and remembers the new **last modified** date) and merges it with the local document. It also informs the user that there were changes upstream and they are getting merged.
* If the user chooses to press "Save" again, then the merged document get pushed with the **last modified** timestamp.
* The server might or might not accept the document, based on the **last modified** timestamp
<br>