-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 22.01.2016 18:43, Christopher Small wrote: > Replicative lets you distribute state, so any time you'd like a > distributed system to be able to share state, this is something you > could consider to do that. In particular, every web application is > a distributed system, so it's something you could use any time you > wanted eventually consistent state between server(s) and clients. > So the real question is what shared state offers. > > If you're not doing shared state, you're probably doing something > where you send messages through some remote transactor that > (ideally) ensures consistency of the system. But that means two > things: > > * You can't be working offline (at least, not without a lot of work > that starts to look like ad-hoc distributed state) * If you want > optimistic UI updates (good for responsiveness & UX), you have to > figure out how to undo UI updates if those transactions fail > > Replicative solves both of these problems. You can work offline on > your copy of the data, and then when you're able to reconnect, it > does a "merge" (analogous to a git merge). Ideally, the merge is > clean and the remotes get copies of the work you did, and everyone > is happy. But, if there are any kind of conflicting changes that > need to be merged, you have to go through history conflict > resolution process, again, quite like you would have to in git. > > So in very broad strokes, replicative is sort of like auto-synced > git for application data.
Yes, this description is pretty accurate :). There is no example for manual conflict resolution yet, but we already have a commit graph visualization to allow analysis and time travel (not implemented yet, but the vega.js plot routine should work in cljs apps): https://github.com/replikativ/flechtwerk Originally the plan was just to implement something like git for data. But over the last year I have refactored it a few times, so now any CRDT can fit and replikativ just covers the distribution for you. The C in CRDT most often stands for "conflict-free" (we prefer "confluent", because CDVCS represents conflicts in its value), so if you pick other CRDTs, e.g. sets or a LWWR you don't even have to do conflict resolution and just have an eventual consistent datatype. > > Chris > > > > On Thursday, January 21, 2016 at 9:00:28 PM UTC-8, Teemu Kaukoranta > wrote: >> >> Thank you, this looks immensely interesting! I'm still having >> trouble understanding when exactly one should use replikativ; are >> you saying it will make it easier to build offline applications? >> You might have a look at Nikita's very nice blog post: http://tonsky.me/blog/the-web-after-tomorrow/ He has a slightly more central take on distribution, as there still is one authority ordering the transaction log. Replikativ + CDVCS also allows you to fork data and dissent on its state, so you are allowed not to converge with another writer. But even if you only allow offline edits, you basically have to deal with conflicts, which is not really avoidable in his centralized design as well. >> >> There's two things that make this difficult to understand: its >> academic nature, and the fact that many of us are just so used to >> the central server that it's hard to imagine anything else. I am sorry for this appeal, I really tried to explain it well and give good examples including a non-trivial prototype application (https://topiq.es). Why do you think it is academic? I have written a paper and teamed up with the syncfree group for CRDT research, because many eventual consistent (NoSQL) systems promise things which they don't deliver and are poorly documented (read aphyrs Call me maybe blog series to get scared...). basho is in this research group as well btw. and is building state-based CRDTs into Riak. I wanted to put the ideas and concepts under serious scrutiny and give very high quality documentation about the core design. But my motivation is not academic, it is rather practical and political: I love data and I love machine learning, but the current trend is that data is always privatized. What can I improve to make it more clear that this a very practical project? Christian -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJWonqNAAoJEKel+aujRZMkZeYIAL5LC2wkPGh2prbq0ZHeIXOv WKFV1BA7uDF9IzfhGBK6Wgs0t++wsHQu+1ovZlDPM0XDliQ7/tIdONsZi2Cud15T oPrXVmyjJ8KEZXl9Skb9dEwVw79d8ZPYEdO75MoJB9+/bebad2H1ol1n3NEQYdVw GRbGLiGhOgJPzR5N/VVV8H/OFhtywxy0VYC9PRCB6N2EPpJvMPvBUyObhbGjEOCI ci2yNrsmA1lVRMoWtxoHlPKfOWdpRqM5Snr2gzGhB6xGa6lUYcF0t7xGy0zP6tcd luCtdtbcX1BTPu+xYmDJS9s2lP3L0xOiGblVTOv07Kjlgy6bwRNQL/LFRm/GOeU= =LY3W -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
