gritzko / ron

(dated, see the site) Replicated Object Notation, a distributed live data format, golang/ragel lib

Home Page:http://replicated.cc

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

How do CRDTs map to RON?

flanfly opened this issue · comments

I'm working on an implementation of RON in Elixir and have a bit of trouble understanding how the reduce function of basic CRDTs work.

This is what I could gather from this project as well as the Gitbook on Swarm 1.0.

LWW

LWW are associative dictionaries. The location of an op holds the key, the atoms hold the value. Reducers sort all non-header and non-query ops by location and delete all but the latest (by event timestamp) op for each location.

Tombstone Sets

Ops adding elements to the set have location zero and a single atom. This atom is inserted into the set. Tombstones have no atoms and their location is the event timestamp of the op that inserted the value this tombstone marks as deleted. The reducer can simply append new ops.

RGA

This is where I have the most problems. Reading @gritzko paper my instinct was that each op's location contains the event timestamp of the previous op (the causality relation). In the words of the paper an op is a atom5. Insertion ops have a single atom and tombstones no atoms. But reading this implementation and the test files it seems that only tombstones/backspaces have their location set to non-zero values. And the causality relation is (somehow) realized via the event timestamps. What am I missing here?

I wrote some ersatz docs — https://github.com/ff-notes/ron-rdt-spec (with fixed test data)

The better docs are being written.

What you refer to as "Tombstone Sets" are actually Observed-Remove Sets.

The @gritzko's paper about Causal Trees has no common with RGA. For example, CT adds backspaces after a character, but RGA replaces it with a tombstone. I think this was the missing part.

In general, RGA uses the idea of an abstract causal tree, not @gritzko's concrete Causal Tree. More discussion on this can be found in http://archagon.net/blog/2018/03/24/data-laced-with-history/

Thanks for clearing that up! The ersatz docs are really helpful.

The @gritzko's paper about Causal Trees has no common with RGA.

That's suprising. The Go implementation says in rdt/rga.go:

// RGA is a Replicated Growable Array data type, an ordered collection of anything
// (numbers, strings, objects). This algorithm is actually closer to Causal Trees,
// albeit that name may turn confusing (RG Arrays are actually trees, Causal Trees
// are actually arrays, but nevermind).
//
// Algorithmically, this differs from Operational Transforms by bruteforcing the
// problem: all the elements of an array have unique ids, so concurrent changes
// can't introduce confusion.

That is abstract philosophy, I understand what Victor meant (I think I understand), and my opinion is different. Anyway, that comment doesn't describe implementation detail at all.

I'll use your docs and test files. Thanks again!