- Apr 2024
-
-
With this strategy, the rendered result is
Tags
Annotators
URL
-
-
docs.yjs.dev docs.yjs.dev
-
I get a new ClientID for every session, is there a way to make it static for a peer accessing the document?
Would be nice to have truly unique ids. E.g., a public key.
Eats more space, but can be zipped over the wire. Given there are many ops transferred.
Also could be possible to create pubkey -> int mapping per-document, so it's damm more compact. That would require consensus on this map.
-
-
Local file Local file
-
Furthermore, due to its design, the garbage collector inYATA may break late join mechanisms. This is becausewhen a user is offline for a period longer than t seconds,it will still hold references to deleted operations, while on-line users who already performed certain removals do not.Therefore, YATA does not support garbage collection for asite while it is offline.
So, whenever there's constantly > 1 users offline on a doc - can't garbage collect / compact.
-
From our practical experi-ences and the use in production, such a delay is sufficientto ensure that content will be removed safely, without anylosses that may lead to inconsistencies
User may go offline for more than 30 seconds. The approach seems brittle
-
We denote an insert operation as ok (idk , origink , lef tk ,rightk , isDeletedk , contentk )
That's plenty of metadata.
Why three refs? CT showed that one's enough.
Also strange that deletion mutates an op, rather than being another op. Seems it'll be hard to manage it (undo/redo).
-
Upon its creation, the operation thus gets as-signed a unique identifier which is composed of the useridand the current operation counter
It's unique as far as user behaves, not creating ops with the same id.
Hash of an op would be a good id. Although it does not come with a counter. So counter, if we need it, is in the op.
-