Description
Many collaborative apps need a way of sharing real-time updates with other users without persisting those updates. This happens when the real-time updates are useful for communication with other users, but have no long-term value. For example:
- Pixel-by-pixel updates while dragging an object (when the object is released, its final position should be persisted, but it is not necessary to store all the intermediate positions while the dragging is in progress)
- A user's current cursor position and selection in a text editor (if other users' cursors should be displayed)
- A user's current mouse pointer position in a graphical app (if other users' mouse pointers should be displayed)
In these situations, it would be possible to make all those changes part of a document, but it would be wasteful, since nobody is interested in the history of all those fine-grained updates, and there can easily be many updates per second.
One option is to leave such transient updates entirely out of Automerge and to communicate them via a separate real-time channel between users. However, this adds complexity to the app, since it needs to merge the persistent state with the real-time updates: in the object dragging example, the current position of an object may be determined either by that object's persistent state or the latest real-time update to that object's state, whichever is newer. When a dragging operation begins, the real-time updates start taking precedence over the persisted object position, but when the dragging is complete, the object's persistent position is updated and the real-time position updates are no longer valid. This potentially fiddly logic might better be implemented in a general-purpose library, so that the app doesn't have to deal with this complexity.
Another concern is that the currently proposed mechanism for cursors (#313) requires the cursor object to be part of an Automerge document in order to be able to convert between the cursor's elemId and its index. If cursors are only communicated out-of-band outside of Automerge, we cannot use this mechanism.
This suggests that there should be a way of making ephemeral updates to an Automerge document in a way that allows those updates to be shared over the network, but without persisting those updates. @pvh has suggested that one possible implementation would be to use separate actorIds for the persistent and the ephemeral changes, and allow ephemeral changes to depend on persistent changes, but not the other way round.
Another thing to keep in mind is that there may be interplay between ephemeral updates and the undo feature (#318). We probably don't want to retain undo history for ephemeral updates, but cursor positions sometimes need to be updated on undo: for example, in a text editor, standard behaviour is that when you undo an insertion/deletion, the focus is moved to the place where the undone edit occurred. Not yet sure how best to model that, but it's something to keep in mind.
Activity