It doesn't look like you have. I watched the demo video "GUN Survives a Primary Fault" and the conflicting updates were resolved with a LWW semantic, which is non-deterministic.
(EDIT: I read some docs, and it looks conflicts are resolved by choosing the highest lexical order of the value. So, apologies for the assumption. I assumed LWW because the BBBBBB update was seen last after the fault was resolved. Nonetheless, I think it is interesting you're treating the browser as a peer in the system, and not simply a client)
> this is now available to developers - with or without the academic side.
I don't understand this attitude. Working closely with academics ought to be what industry strives for. They take the time to research, formalize theorems and write proofs to advance the current state of the art in Computer Science. This research helps move industry forward. A tight relationship between industry and academia is mutually beneficial, for what should be obvious reasons.
Thank you for looking at it! But I do need to correct you, it is not using LWW semantics. To be clear, LWW isn't possible in a decentralized system because "last" is different for every peer. Only a centralized system can have a "last" because it has an objective place to measure last from. GUN is using a deterministic merge function, not LWW.
Academia - I agree with you! Good words, sir. I was just wanting people to know that it does exist in code land as well, because often times academic designs aren't. So I think it is important to highlight when they are available.
managing the # of actors, safely dealing with tombstones and reducing space complexity are just a few reasons why one might want CRDTs on the server side.
Not only that, why make every user reimplement the same resolution strategies? Or make Basho dev's reimplement them for each official client? You'll increase the chance for bugs or subtle semantic differences. Also, many users don't know or want to understand conflict resolution. They want a data structure that just "does the right thing". This is most easily achieved by baking it into the database itself.
Disclaimer: Former Basho developer with a lot of pride in the 2.0 release.
Can you add (or link to) something with more details?
"Managing the # of actors" doesn't make much sense to me without further context. I know that Erlang is actor-based, but that shouldn't matter if I'm e.g. a client of the system? Also, I'm not sure what "safely dealing with tombstones" would mean -- what additional safety is added by "server-side" CRTDs which cannot be achieved with client-side code (and how so?). (Etc.)
Full disclosure: I’m a current employee of Basho Technologies.
Other than some supporting work [1] [2] introduced into 2.0 to provide advanced causality tracking, you’re correct in assuming we could have introduced more [3] CRDTs as part of the Riak 1.x series. We could have also implemented all of the CRDTs we provide in the client as well, which is similar to what the SwiftCloud CRDT reference platform does.
There's a couple important things to note here, however:
* When talking about merging conflicting writes, we are specifically referring to state-based CRDTs, not operation-based, which is what we have implemented in Riak.
* Retrieving conflicting writes from the client, or siblings as we call them in Riak, requires bringing all of the siblings to the client, performing the merge operation, and shipping the updated state back. Given this, the number of siblings an object can have on disk, assuming all merge operations happen at the client, is potentially unbounded if you never ever read, and only ever write. When implemented on the server, we can ensure that we perform this merge operation during both the read and write cycle, keeping the sibling count down to one and reducing the amount of state we need to ship to the client.
* In addition, we use the coordinating node (really, a combination of virtual node and partition index) of the write as the "participant" or "actor" for the operation. This is not to be confused with actor model based languages. This allows us to have better control over actor growth; when dealing with clients all writing to CRDTs, every single particpant needs to have a unique actor id. Recall, that most of the CRDTs track actor counts, for instance the G-Counter which is structurally equivalent to a vector clock, although semantically different. This introduces a problem of garbage collection. Interval tree clocks, is one such solution for addressing the problem, but can not be used as the basis for some CRDTs. [4]
* Finally, there is work underway in making state-based CRDTs more efficient through "delta-CRDTs" [5], which allow for a more efficient optimistic and anti-entropy repair mechanism.
While the most notable resource for exploring CRDTs continues to be the comprehensive report by Shapiro, et al, [6] in practice many of the data structures outlined here have unbounded growth in garbage (specifically referring to items such as the OR set, which tracks an object for every operation performed). Therefore, we rely on some of the more optimized representations which don’t accumulate garbage. [7] In addition, the conflict-free, composable, replicated map structure, which is provided by Riak 2.0 was specifically invented by Basho, and it is the first of its kind. [8] It took many hours and iterations on QuickCheck models to ensure that, given somewhat arbitrary composition, that merge operations happened correctly. This is why there has been interest in exploring alternative ways of checking or building these models. [9]
By storing these CRDTs at the server-side, we also are able to provide a operation-based interface for interacting with these objects from all of our clients, and leave the complexity of implementing the CRDTs out of the client. This additionally allows for our search offering, Yokozuna, to be able to index these data types and provide query over their values.
CRDTs can either be commutative or convergent; much of industry and academia have settled on the opaque "conflict-free" instead of CmRDT/CvRDT for simplicity
I was speaking with Eric Redmond about this conference last week. Sounds more interesting than a conference about writing documentation might initially appear to be.
Calling the game market "sinister" borders on hyperbole.
Horia Dragomir and Stephanie Kaiser from Wooga gave a presentation[0] on metrics driven game development at GOTO Copenhagen earlier this year. Through the lens of one of their more popular franchises "Monster World", they discussed, among other things, A/B testing and the surprisingly short life (days to weeks) of a game feature before it becomes irrelevant. Nothing in their talk suggested late night meetings in dark corners, plotting to turn their users into addicts. Rather, they discussed adapting to rapidly changing trends and patterns--which sometimes but not always included introducing new in-game purchase items.
If on the surface the game industry as a whole appears to you to be an online equivalent of a casino, thats fine. What I see are dedicated and passionate engineers trying to ensure the survival a product in which they've dedicated years of their lives to getting right, by employing many of the same techniques nearly every other user facing tech company uses everyday, and I for one am not ready to cast the first stone and accuse entire industries of moral bankruptcy.
There are surely very dedicated people working in some casinos. That doesn't have anything to do with them doing interesting stuff.
And the fact that they use "what every other user facing tech company uses" is exactly the problem. I like and use A/B testing, but it's purpose as a tool is to take decisions based on what extracts the more money from users. There's no dark corner, but the goal is definitely the same. And it's not exactly something that I want to associate with games.
The fact that your whole post, and a big part of the link you give, is as much applicable to selling games as to selling rocking chairs or any random saas product is exactly the problem. Marketing and sales come first, game development is merely an afterthought.
