3 ms·
Because asynchronous edits would never be applied with that system. If I make local edits to a document and you make remote edits to a document, the hash for y
by fastball 3y ago
Because asynchronous edits would never be applied with that system.
If I make local edits to a document and you make remote edits to a document, the hash for your "expected state" will never match my document's state in the future because I have already made local changes.
Yes, CRDTs require all clients receive all edits in order to guarantee convergence, but the updates not needing to be applied in a certain order (which is what you are proposing) is an important property for real-world distributed use-cases.
- steve76 3y ago[dead]
- jakelazaroff 3y agoThat’s only the case for CmRDTs, right? AFAIK CvRDTs (which send the whole state with every request) don’t impose any constraints on message order.
- fastball 3y agoAh, a bit of an "eats shoots and leaves" situations here. I mean: Yes, CRDTs require all clients receive all edits in order to guarantee convergence. They indeed do not need to be "in order", they merely need to receive all edits "to guarantee convergence". My insertion of "in order" was definitely confusing there.
- jakelazaroff 3y agoOops lol. I guess that applies to CvRDTs as well, since receiving a given state also means receiving all edits that caused it?