-
Notifications
You must be signed in to change notification settings - Fork 467
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Alternative implementation of cursors #313
base: performance
Are you sure you want to change the base?
Conversation
Link operation is currently unused (it was previously there for undo, but we have removed the undo feature for now). The chldActor and chldCtr columns were only used by link operations, so they can be removed too. However, for cursors we also need an (actor, counter) pair to reference the list element in question, so I'm renaming these columns to refActor and refCtr and will use them for cursor storage.
For now it just stores the elemId referenced by the cursor in the backend, updates the frontend-backend protocol to handle cursors, and instantiates Cursor objects in the frontend. Does not actually perform the conversion from elemId to index yet; that's next.
This PR is now mostly complete and working: cursors can be created and stored, and indexes are automatically recomputed as needed. There is one known issue: |
This PR provides an implementation of cursors, which allow a particular element of a list, or a particular character in an
Automerge.Text
object, to be referenced from elsewhere in the same document. The API involves a newAutomerge.Cursor
class, and it can be used like this for lists:and like this for Text:
The key thing about a cursor is that its index automatically updates when the list/text it references is changed. In the examples above, the index updates to 3 if you insert a new element before the cursor position, and it updates to 1 if you delete an element before the cursor position. If you delete the element that the cursor points to, the index is set to the index of the closest preceding element that has not been deleted (or -1 if there is no such element that has not been deleted).
The implementation of cursors on #307 requires a direct call from the frontend into the backend, which is inconvenient when frontend and backend are on different threads. This PR is an alternative implementation that is integrated with the existing frontend-backend protocol, making it compatible with multiple threads. This PR also includes a way for cursors to be efficiently represented in the binary storage format for changes and documents. A downside of this approach compared to #307 is that this PR requires cursors to be stored within the same Automerge document; it is not possible to store them somewhere out-of-band, or in a separate document.