gritzko / replicated.cc Goto Github PK

It would be helpful from a conceptual point of view to list all of the RDTs together, whether implemented or not, to help users of RON understand what kinds of things are or will be RDTs.

Currently, the RDTs page lists the following Built-in RDTs:

LWW: Last-Write-Wins Object
RGA/CT: Replicated Growable Array / Causal Tree
TXT: Collaborative text
Sets
Counters
Binary blobs

As mentioned in #15 , TXT is a mapper, not an RDT (AFAIK).

Is this a complete listing? What is it based on? (i.e. is it based on various research in the field, or a roadmap, or simply "things that work now"?)

Additionally, I see the following RDTs in the ron-cxx code base:

    LWW_RDT_FORM = 13,
    RGA_RDT_FORM = 14,
    MX_RDT_FORM = 15,
    MAX_RDT_FORM = 19,

Only LWW and RGA intersect with the replicated.cc RDTs page.

There are some other variations of RDTs mentioned in the RON-RDT Composition page as well:

OR-Set
LWW-per-field

Perhaps we could show a "status" next to each RDT to indicate if it is implemented or planned.

In the frames page, the following explanation is given of a raw frame:

Raw frame is just a group of operations client sends to the peer. It contains delta, or patch — list of changes that client wants to be applied.

It's unclear what a "client" or "peer" is in the context of frames. This might be better suited to a page explaining what a frame is in the context of a particular peer-to-peer implementation? swarmdb perhaps?

It seems like TXT is a mapper, not an RDT. It's listed under "Built-in RDTs" at http://replicated.cc/rdts/

The Replicated Data Types page starts off explaining functions in terms of frames:

Internally, RDTs works as pure functions: `f(state_frame, change_frame) → new_state_frame`. Where frames are either empty frames or single ops, or products of past reductions by the same RDT.

but then switches to using state, patch, and op as the thing passed to the function:

e.g. `f(f(state, op1), op2) == f(state, patch)` where `patch == f(op1,op2)`

A little later, it explains: A `change_frame` could be an op, a patch or a complete state.

It would be helpful to unify the terminology, perhaps using "op, patch, state" as the possible things a "frame" can be.

The ops page makes the following statement:

Consequently, an op may have one of 16 patterns, depending on the versions of its id and reference. RON defines following combinations:

It then lists 7 of the 16 patterns. What is the significance of the other patterns?

I think we could more cleanly separate RON from Swarm. I may be misunderstanding the nature of the project(s). But I think it would be easier to understand RON if we could explain it without Swarm. So for example, in the RDT page, there are references such as:

"RDTs are a Swarm term for object types."
"Swarm uses that RDT to correctly process..."
"A mapper is a Swarm term..."
"Mappers turn Swarm objects into JSON..."

What is the relationship between RON and Swarm? Can these references be removed / changed to "RON"?

The spec says:

When unambiguous, prefixes could be omitted: 1099 3.14 D4ICC+XU5eRJ.

But 1099 is actually ambiguous: it may be parsed either as an integer 1099 or as UUID (0x40249000000000, 0).

Is it a wrong example in the spec or ambiguity is actually considered automatically resolved to integers?

Either way, the spec must clarify it.

I find the "RGA / CT" distinction confusing. It seems Causal Trees are a broader datatype than Replicated Growable Arrays, but we keep referring the concept as both RGA and CT.

If Causal Tree is a superset of RGA, can we do away with the "RGA" terminology, or at least describe it as a subset-type of Causal Tree?

There is a comment in the ron-cxx code that further confuses me:

/** Implements Causal Tree CRDT, which is mostly the same thing as Replicated
 * Growable Array CRDT. Except, RGA is stored as a tree, while CT is stored
 * as an array. We store everything as a RON frame.
 * We call it use "RGA" cause every RDT here is a CT (in the broad sense). */

Shouldn't RGA be stored as an array, and CT be stored as a tree?

A large part of the RGA/CT page is focused on explaining how RON 2.1 differs from RON 2.0. This will be valuable to people familiar with the project, and should remain documented, but as an "explainer" on what RGA/CT is, it distracts from the main points.

Suggestion: Rework the article to explain the new Causal Tree RDT, then as a footnote or subsection near the bottom, explain how it's similar to the old RON 2.0 RGA (if I understand the progression between these two versions of RON).

Glossary refers to "mappers" in "Other Terms / Deriveds" but doesn't define the concept.

Regarding the UUIDs page (http://replicated.cc/uuids/):

The claim is made that Microsoft GUIDs are "43 chars of hex" and provides the example Compare: `1fLDV+biQFvtGV` and `{G4G3G2G1-G6G5-G8G7-G9G10-G11G12G13G14G15G16}`

But I think from the RFC mentioned, UUIDs are actually 36 chars (or 38 with braces):

{25b2e030-ecb0-44be-b4fe-ae79fa75f495} (38 chars, including braces)

The replicas page introduces several concepts that aren't talked about in other areas of RON documentation:

• replica
• primus
• peer
• client
• session

Should this be moved to a more swarm-specific page, perhaps?