I'm trying to recreate the example shown in Figure 4 from the sited paper: Concurrent editing of an ordered list of characters (i.e., a text document).

I use the following code:

package main

import (
	"encoding/json"
	"fmt"

	jsonpatch "github.com/evanphx/json-patch"
	"github.com/gpestana/rdoc"
)

func main() {
	docA := rdoc.Init("a")
	docB := rdoc.Init("b")

	if err := docA.Apply([]byte(`[
		{"op": "remove", "path": "/x/1", "value": ""},
		{"op": "add", "path": "/x/1", "value": "x"}
	]`)); err != nil {
		panic(err)
	}

	if err := docB.Apply([]byte(`[
		{"op": "add", "path": "/x/0", "value": "y"},
		{"op": "add", "path": "/x/2", "value": "z"}
	]`)); err != nil {
		panic(err)
	}

	opsA, err := docA.Operations()
	if err != nil {
		panic(err)
	}

	opsB, err := docB.Operations()
	if err != nil {
		panic(err)
	}

	docA.Apply(opsB)
	docB.Apply(opsA)

	buildDoc(docA)
	buildDoc(docB)
}

func buildDoc(doc *rdoc.Doc) {
	buffer, err := json.Marshal(*doc)
	if err != nil {
		// handle error
		panic(err)
	}

	patch, err := jsonpatch.DecodePatch(buffer)
	if err != nil {
		panic(err)
	}

	modified, err := patch.Apply([]byte(`{"x": ["a", "b", "c"]}`))
	if err != nil {
		panic(err)
	}
	fmt.Println(string(modified))
}

However, this yields two different documents:

{"x":["y","a","z","x","c"]}
{"x":["y","x","z","b","c"]}

According to the paper, {"x":["y","a","x","z","c"]} would have been correct (which neither gave). More importantly, the documents don't seem to converge.

Upon further inspection, it looks like the operations are the following:

[{"id":"2.6422626","op":"remove","path":"/x/1","deps":[],"value":""},{"id":"3.6422626","op":"add","path":"/x/1","deps":["2.6422626"],"value":"x"},{"id":"2.6488163","op":"add","path":"/x/0","deps":[],"value":"y"},{"id":"3.6488163","op":"add","path":"/x/2","deps":["2.6488163"],"value":"z"}]

[{"id":"2.6488163","op":"add","path":"/x/0","deps":[],"value":"y"},{"id":"3.6488163","op":"add","path":"/x/2","deps":["2.6488163"],"value":"z"},{"id":"2.6422626","op":"remove","path":"/x/1","deps":[],"value":""},{"id":"3.6422626","op":"add","path":"/x/1","deps":["2.6422626"],"value":"x"}]

I suspect the issue is with the premise of using JSON patches for arrays. Given the path references an index in the array, the index would have to be adjusted given the operations that took place before it (similar to who OTs work).

Current implementation is using a list insertAt which uses list indices rather than values. This will create inconsistencies in the final state in cases such as example 4.

It would be helpful to have an example on how to build a resulting JSON doc. I assume we use the MarshalJSON() method and the jsonpatch library to create the end result. However, this is just a guess.

JSON patch creates and applies patches for JSON data structures. This library seems to be a good fit to provide a high-level interface for developers to use rdoc.

tasks

• Define API merging and manipulating rdoc structures
• Create and apply JSON merge (https://github.com/evanphx/json-patch#create-and-apply-a-merge-patch)
• Docs update + add examples

It's an alternative to the more verbose JSONPatch. Do you see any reason why it wouldn't work the same way given your logical clocks? I'm considering implementing it with the same basic structure but creating much smaller patches over the wire.

Refactor the operation struct and its methods based on the new specs.

https://github.com/gritzko/ron, maybe it will be usefull

Create/refactor the doc struct and its methods based on the new specs

Create each and every type defined by Doc:

• list
• map
• register

Create examples to show how the CRDT interface works.

I don't see where/how you are extending JSONPatch to include id and deps to be generated on a remote server. Do you have a full example of this?

Refactor the project interface for exposing the 3 interfaces (user, network and doc) as described on the new specs

Define and document API for interacting with the CRDT document.

This looks really interesting. It's great to see crdt being attempted.

It looks like an OT based crdt. I was wondering what is the current status. For example has a test harness been developed yet to prove that all instance types eventually become consistent over time ?

Thanks for this great work. I hope I can help move it along.

The current implementation is assuming that the document is mutable. This might eventually become troublesome and harder to understand the code due to side effects in the structure.

Think about and implement an API in which the document is immutable. E.g.

doc := crdt.Init()
doc1 := doc.Merge(...)
doc2 := doc1.Apply(...)