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. :) 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. > > 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? Again, this is not really what I think, just trying to put myself in the shoes of devs who don't understand replikativ yet. :) 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. This project is looking great, and it's clear to me that you're a very skilled maintainer who cares about the project! -- 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.
