alex-shapiro / ditto Goto Github PK

It would be nice if Site ID was not limited to u32 as a datatype, and instead could be anything that implements the traits needed to function. (I.e, Serde traits + Eq and Hash). I'm not sure how tightly coupled the implementation is to u32 at the moment.

This would allow a more decentralised approach at Site IDs, by using something such as a Random UUID to be used in place of a u32

Hi

Could you comment / compare ditto implementation with JSON CRDT paper ( PDF )?

Is it using same principles and algorithms or not? What are the differences?

There are Scala and Haskell implementations of JSON CRDT based on that paper:

• https://github.com/fthomas/crjdt
• https://github.com/amarpotghan/crjdt-haskell

Curious if this supports garbage collection concepts?

Should map_value here not have the capacity of self?

map_value.0.reserve(self.len());

A special Counter type for mutable numbers. Unfortunately, incrementing a raw number is not idempotent, so receiving duplicate increment ops on a raw number breaks consistency.

The most basic implementation of a counter is one that keeps track of its entire history; each increment has a (site,counter) UID and duplicate increments have identical UIDs. The struct would look like this:

pub struct Counter {
    value: f64,
    history: Vec<UID>,
}

pub struct UID {
    site: usize,
    counter: usize,
}

pub struct Increment {
    amount: f64,
    site: usize,
    counter: usize,
}


impl Counter {
    pub fn increment(&self, amount: f64, replica: &Replica) -> Increment {
        self.value += amount;
        history.push(UID{site: replica.site, counter: replica.counter});
        Increment{amount: amount, site: replica.site, counter: replica.counter}
    }
}

Using BTree instead of Vec will improve performance when editing large arrays.

Just found this cool library. Thanks for the awesome work you've put into it!

I'm relatively new to the ideas underlying CRDTs but having a great time digging into various research papers and other sources on the subject. I plan to dig into your code more deeply soon, but was wondering if you could provide any additional information about how the CRDTs are implemented in this library from a high level? For example, in the readme, you mention "As long as ops from a site are executed in the order they were generated, the CRDT will maintain consistenct." Does that mean that this library is built out using CmRDTs and that I have to guarantee delivery order over my transport?

Thanks in advance!

I'd love to use this with a JavaScript front-end. Any recommendations for having it work with a JavaScript client over HTTP?

Also, are you basing this library on CvRDTs (convergent replicated data types) or CmRDTs (commutative replicated data types)?