-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21.01.2016 17:46, Herwig Hochleitner wrote: > This is great and I like the direction, you're thinking in. Have > you seen the talk "I see what you mean", by Peter Alvaro > <https://www.youtube.com/watch?v=R2Aa4PivG0g>?
Yes, and I just rewatched parts of it. I also read the paper: Dedalus: Datalog in Time and Space in autumn and just had a look at it again. http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-173.html If I recall correctly Eve from Chris Granger is also drawing on this. > If so, can you give me your take on the Relation between CRDTs and > his usage of Datalog and Relational Algebra to achieve confluent > computation? For me this is the most important task to make distributed systems practical, for instance in the CRDT community the biggest problem is not of technical nature, but how to make modelling of application state (composition of CRDTs, eventual consistency) reasonable for developers :). There are of course some problems with CRDTs themselves (e.g. metadata size), also in replikativ, but I would consider them secondary atm. So we need to make the distribution of data in a p2p system reasonable for developers and I think the crucial part is how to combine it with Datalog (for me mostly Datascript atm.), while still exposing the write-semantics of the CRDT. I really like to have Datalog (in form of Datascript and Datomic) as an application developer and both my example projects (topiq and cnc) used CDVCS' to distribute the transaction log for these systems. But it is not yet clear to me how to make it really practical for other developers and more applications. The git-like sequential nature of the CDVCS approach to model the transaction log in an understandable way is my first take to distribute Datalog. You then need to resolve conflicts in the commit-graph either automatically (if transactions commute) or manually. Dedalus is coming completely from the logic programming direction and elevates time into a first class concept in the queries to then allow some monotonicity constraints at query time to reorder distributed asynchronous operations (in combination with their "choice" operator). You still need to be able to encode (non-)commutativity or your queries won't return results to my current understanding, so you have the same problems, but in a more formalized way. Also logic programming in very complex unifications with unintended conflicts can be difficult to debug in my limited experience. For now distributed computing is WIP and a pure logic programming approach is monolithic and not decomposable in my opinion. For instance I also don't think you would always want to use Dedalus, e.g. for performance (games) or efficiency (IoT) reasons. My take is to use simple datatypes (CRDTs) to cover the replication (the annoying IO problems like network and storage) and then model a local Datascript instance on each peer. The problem that Dedalus is struggeling with is monotonicity and commutativity of operations, but this can also be addressed on each replica, CRDTs are already covering distribution and convergence. So concretely I think you can implement Dedalus with Datascript and replikativ by making time with the successor relation first class and put all transactions in a grow set which you stream into Datascript on each replica. The conflicts are automtically resolved at query time than with Dedalus semantics. To distribute the transactions I think a grow-set would suffice. A G-set CRDT is very easy to implement in replikativ now. But I might miss some crucial details here... Actually this sounds quite interesting :D. So I would say that CRDTs and Datalog/Dedalus are mostly complementary. Peter Alvaro talks about the fact that the query engine should decide how to partition queries and distribute sate, but I think we are not there yet. On the other hand CRDTs already scale very well in many cases. Have you had a look at bloom? I haven't so far. But even if Dedalus would be a sufficient approach for service providers it would still mean that all participants need to agree on the semantics. (1) In the Clojure attitude I rather think we need a toolbox of simple composable concepts to explore the design space and reassemble them depending on the application. Does this make sense to you? What do you think? Christian (1) As remark in regard to a calculus to force logical consistency, convergence is most often modelled by the technical community as some technical property and distributed systems are thought of as a pure technical problem. I would like to point out that society is also a distributed system and a reason why I wanted to have conflict resolution in a git-like fashion in CDVCS and in an open replication mechanism is to allow dissent and a democratic discourse. I have worked on a wiki-based voting system before (Votorola) and I think the interesting part is to potentially put humans in the loop as well to resolve conflicts. We do this all the time in social relations, because in fact humanity is a distributed system of brains (to put it in embarrissingly cybernatical terms). -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJWo5yMAAoJEKel+aujRZMkFOQIALIgz5KkHkjNH8W5SW1XNJ73 LewfEDqL91DIhPJ6wc4efauEpaW/mHX8ezriyZcOSKekHKF6b07w++ZP0salDgoE 141oDBl9TkvZcv71tAW8nLxK1zNJ3oDXUYlKOyE0iU9e5XPowfMn/4zTTUnwqvdb 1oo6mI/RW7CZnxFBtmooYic9nV+vFFoa9LPss2/K+xM11g7z5lkkDnF/uRmt9Zgm 0T72sbK/XTWWebKoloFWirk0kgVqEeRj48IK4uS6i8bbwpfvRO+wY1FHJMQeXumq n4BMxIgUoLnugwAgTPWdcE0BJBCDIiD7oMjQjnmHpcU5makApMKNIOfMY8p+pVA= =ooZy -----END PGP SIGNATURE----- -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at https://groups.google.com/group/clojurescript.
