I came to similar conclusions while reading the JSON CRDT paper by the same author. It closes with essentially “garbage collection is TBD”, which makes it also not feasible in practice for the same reasons ermouth outlines.
Best Jan — > On 7. Aug 2020, at 03:08, ermouth <[email protected]> wrote: > > Both CRDT and OT (operational transform) are implementable over CouchDB. > CRDT approach is ok for Couch/Pouch built-in MapReduce mechanics, esp if > complicated combining reducers are executed client-side (ie no 64Mb for JS > instance limitation). Best results however are achieved if a finalizing > part of a reducer is put out of Couch/Pouch. > > As anything ‘magic’, CRDT collab scheme, esp if there’s a goal to implement > a text editor, has its price. > > The entire text should be split into lower-level atomic blocks, say words, > or even characters, and each should be stored as a separate entity inside > JSON obj or array. Each action (insert/delete of an entity) is then stored > as a separate doc, then distributed over collaborators using _changes, and > then re-combined at each client. So, half a kilobyte text easily bloats > into hundreds of docs and hundreds of kilobytes of JSON data. > > Since we store each modification as a separate doc, there’s absolutely no > way we can get conflicting doc revisions, so the problem of conflicting > docs just never happens. > > I’ve tested the CRDT collab approach over CouchDB, found it viable, however > dropped it for enormous storage overhead. So, excessive storage is the > problem, not conflicts or speed; however, bloating is inevitable with CRDT. > > ermouth > > > чт, 6 авг. 2020 г. в 01:09, Bill Stephenson <[email protected]>: > >> There have been 3 submissions of a paper about "Local-First" apps ( >> https://www.inkandswitch.com/local-first.html < >> https://www.inkandswitch.com/local-first.html>) to Hacker News in the >> past week. Twice it made it to the front page and the most recent was there >> most all day and was still on the 2nd page the next morning. >> >> The paper mentions and discusses CouchDB but I think it drifts quickly >> from the subject of "Local-First” apps to conflict resolution and >> overlooked using CouchDB as a data storage layer for Local-First apps. >> >> I thought it’s worth mentioning here because CouchDB makes it easy for >> both devs and users to create and install a Local-First app. A couple >> months ago I made a very simple demo app that demonstrates one way to do >> that. I posted a link to it in the comments on those HN posts and it seemed >> to generate a little interest so I thought I’d share it here too... >> >> https://cherrypc.com/app/editor/setup.html < >> https://cherrypc.com/app/editor/setup.html> >> >> -- >> >> Bill Stephenson >> >> >> >> >> >>
