7 Matching Annotations
- Apr 2024
-
-
Rather than seeing document history as a linear sequence of versions,we could see it as a multitude of projected views on top of a database of granular changes
That would be nice.
As well as preserving where ops come from.
Screams to have gossip-about-gossip. I'm surprised people do not discover it.
-
Another approach is to maintain all operations for a particular document version in anordered log, and to append new operations at the end when they are generated. To mergetwo document versions with logs 𝐿1 and 𝐿2 respectively, we scan over the operations in𝐿1, ignoring any operations that already exist in 𝐿2; any operations that do not exist in 𝐿2are applied to the 𝐿1 document and appended to 𝐿1 in the order they appear in 𝐿2.
This much like Chronofold's subjective logs.
Do the docs need to be shared in full? The only thing we need is delta ops.
-
Peritext works bycapturing a document’s edit history as a log of operations
How that works is not mentioned.
I guess ops are collected into logs, per member, based on their IDs.
A step short from having gossip-about-gossip.
-
but since a given client never uses the same counter value twice, the combination ofcounter and nodeId is globally unique
What stops him?
-
Fig. 4
Uhh, I'd imagine "remove" would refer to "bold" annotation.
Otherwise, there can be another "bold" with t < 20, that would be accidentally removed.
Syntactic intent is not preserved.
-
The key idea is to store formatting spans alongside the plaintext character sequence,linked to a stable identifier for the first and last character of each span, and then to derive the final formattedtext from these spans in a deterministic way that ensures concurrent operations commute
I.e., let's capture user's intent as ops, not their result.
-
- May 2023