3 ms·
I wonder what happens when an edit can not be delivered to 1+ participant(s). Does an edit need aknowledgements from _all_ participants to be persisted? Is it j
by jupiterelastica 4y ago
I wonder what happens when an edit can not be delivered to 1+ participant(s). Does an edit need aknowledgements from _all_ participants to be persisted? Is it just dropped?
- codetrotter 4y agoIn Englebart's system you mean, or in Zed? The appeal of CRDTs is: > 1. The application can update any replica independently, concurrently and without coordinating with other replicas. Along with some other important points. See https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type https://en.wikipedia.org/wiki/Conflict-free_replicated_data_... The featured article also talks about this in detail.
- jupiterelastica 4y agoIn Zed/CRDTs, these two seem synonymous to me since the OP's article is the first I read about CRDTs that I grasped, or so I thought ;) Doesn't the whole process assume that whenever any edit is done (insertion/deleteion/un-/redo) that the edit _eventually_ reaches all participants? So if a single edit is believed to be delivered to all, but actually never made it to a single participant, who resends it? And if it's not resent, then the participants state is inconsistent from now on, no? Edit:autocorrect
- yazaddaruvala 4y agoBecause it’s async first, the client can use both push or pull to receive the events. If you’ve used Git you’ve been using a CRDT (with manual pulls and manual merges). A better CRDT would do both automatically.
- jupiterelastica 4y agoSo, client that was "offline" can just ask a participant to get the edits from his own last one (aka pull), send out bis own offline edits (push) and resolve from there, I See. Actually, that cleared it up, thank you :)