Re:OT and CRDT trade-offs for Real-Time collaboration
by marknadal on Wednesday January 15, 2020 @03:54AM
(#22052690)
You have to choose which type of Array:
1. An atomic Array
2. Fixed index Array
3. Linked list
Now rather than not knowing what magic is going to happen, app developers know what to expect in advance.
So atomic would choose one or the other, not a combined result.
Fixed array 2nd item to 1st which nulls 2nd and makes 1st b, simultaneously also makes 1st A. Cause lower case b is lexically larger than A, you'd get [b, null].
Linked list theoretically could handle it as you suggest.
Re:OT and CRDT trade-offs for Real-Time collaboration
by josemaenzo on Wednesday January 15, 2020 @05:01AM
(#22053023)
Does gun have a built-in "Linked list" in the API? If so, where are the docs? Could not find them.
If not, any paper or doc that explain how to implement it with gun?
Re:OT and CRDT trade-offs for Real-Time collaboration
by marknadal on Wednesday January 15, 2020 @12:29PM
(#22056172)
Started, but never finished. :(
@nmaro has some pretty good stuff.
The cartoon explainers gives an overview.
But you'd probably want to do RGA algorithm or one of the newer ones.
Martin Kleppmann has a pretty good talk with bunch of paper references:
Re:OT and CRDT trade-offs for Real-Time collaboration
by josemaenzo on Thursday January 16, 2020 @03:35AM
(#22062664)
Oh, I see.
Just wondering, How GUN handle a situation like described above when working with Arrays?
Let's say our state have an array like ['a','b'].
What about if Peer-A splice the first element (0) which results in ['b'] and Peer-B wants to mutate 'a' to 'A' which results in ['A','b'] and they both make the mutation at the same millisecond?