-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 22.01.2016 20:35, Teemu Kaukoranta wrote: > On Friday, 22 January 2016 20:53:25 UTC+2, Christian Weilbach > wrote: > >> >>>> 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...). >> > > I want to make clear that I didn't want to imply anything negative > by "academic". Rather I meant that this topic is probably pretty > foreign to many (or maybe it's just me), and this is the first time > I've ever even heard of something called a "CRDT". In fact the > project's github page immediately made me think that this is a real > and practical tool that solves a difficult problem. :)
They are cool, but the basic concept is fairly simple. You just need a datastructure which converges if some operations commute. So think of sets or monotone updates (increasing timestamp). The fancyness comes when you combine these techniques to get better tradeoffs for certain cases, but they can't defeat the CAP limitations. So you cannot have a CRDT which models a strong sequential datastructure like a list and is conflict-free. What they really allow you to do is expose the real tradeoffs in form of datatypes instead of hiding it behind some "NoSQL" abstraction. > > I've actually read the blog post you linked many times, it's such a > great, great post. I immediately thought of it when you announced > replikativ, the blog post is a big reason in why I was so > interested in this. Yes, it is well summarized. :) Also Nikita is doing a great job with Datascript. > > >> >> 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 gave a great example a couple of posts up. To be honest, > when I first read about replikativ I immediately thought about > offline capability and rollback on failed transactions. The problem > is that both of these can already achieved using (admittedly > horrible) ad-hoc solutions, which can probably make people wonder > whether they really need replikativ. It's unclear to me how much > code I have to write to make the "git like" functionality you > mention work (git is an awesome example by the way), and if it's a > reasonable amount, why even abandon my previous ad-hoc solution? I don't think you should abandon a working solution right now. replikativ is still very young and it is not ready for production yet. But for prototyping it can already significantly reduce code and allow you to focus mostly on the app (client-side) in my experience, letting replikativ take care of distribution and storage. > > Again, this is not really what I think, just trying to put myself > in the shoes of devs who don't understand replikativ yet. :) You are right to do so :). > > So to summarize: emphasize the git-like nature & offline and > rollback capabilities. Show how much code it takes, and how many > new concepts devs have to learn. Yes, I want to have interactive time travel in an app, this would be really cool. Hopefully I soon find the time to build it into topiq (or something else). Most developers would love this and it is one of the awesome things about Datomic. > > This project is looking great, and it's clear to me that you're a > very skilled maintainer who cares about the project! > Thank you :) Christian -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJWo6QfAAoJEKel+aujRZMk4eMH/iq9dovkdzkvfBciQHBKrgIA ru0ky39m59Ld/XpxXjDlb7FbV/Wcx+4zybTSuK/K2PnojOqx/ighRo+FMTOHGMhu SHQzXrkNq5jN7DUVzv9+pfv2LuGQGbFZFJt/kfHqG/igC4rNFC7F/F+JwAsOU/Wa 8T3yyg5oq51hwNAGxsOMHQNARh0oG3mP/vZ/U/3eCfeSVrdkg3F3JALlLAH+OEJs QjV7g/pv4WUuLJLsu+UWKV/lFJ4Ry5hbzSBaHDrYiFKbDwCPRfbwwyljdTwO4uNu YzT2bXhB+oRn4CzTq7e9sRdluQNn0IKoYWBeAuqfq54cl9OyI2ndp/zO0bigRss= =mxAA -----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.
