3 ms·
Having a bit of difficulty following this, so I'll break down my understanding of CRDTs and see if someone can help me out. A CRDT can be thought of as an alge
by lacampbell 7y ago
Having a bit of difficulty following this, so I'll break down my understanding of CRDTs and see if someone can help me out.
A CRDT can be thought of as an algebraic structure, consisting of data type D, and a join function. So for all a, b, c in D, it's:
Associative:
join(a, join(b, c)) == join(join(a, b), c)
Commutative:
join(a, b) == join(b, a)
Idempotent:
join(a, a) == a
Partially ordered:
if join(a, b) == b then a <= b
a <= a == true
if (a < b) and (b > a) then a == b
if (a <= b) and (b <= c) then (a <= c)
So given all of that, I am not sure why the example in the article holds. I assume it's a consequence of the partial ordering, but I don't know what the partial ordering is. What's the join operation and what's the data type?
- BoiledCabbage 7y agoI'm just learning this, but it seems to be that in some CRDTs "a" and "b" represent two different edits to the common state made by two different users and the join operations is how you combine those two edits into a single joint edit that will produce the same results regardless of which order the edits arrive at the "server". In other CRDTs "a" and "b" each represent the new states after two users have made different edits to the same common source, and the "join" function is how you combine those independent edited docs/states into a single state again. Ie if you think of fit branches, set of rules on edits to ensure that no matter the order you merge branches back together conflicts can be automatically resolved and will always reach the same end state with the changes "appropriately" incorporated.