> <i>Because gun is not a database (NoDB), it is a persisted distributed cache. The fatal flaw with databases is that they assume some centralized authority. While this may be the case initially when you are small, it always ceases to be true when you become large enough that concurrency is unavoidable. No amount of leader election and consensus algorithms can patch this without facing an unjustified amount of complexity. Gun resolves all this by biting the bullet - it solves the hard problems first, not last. It gets data synchronization and conflict resolution right from the beginning, so it never has to rely on vulnerable leader election or consensus locking.</i><p>That's some of the most hand-wavy drivel I've ever read.
Seems a <i>lot</i> like CouchDB/PouchDB. Which makes the fact that the words "couch" and "pouch" do not appear anywhere on this page rather concerning to me, because the obvious questions I have are:<p>1. How is this better than CouchDB<p>2. How does this differ from CouchDB<p>3. Why did you not implement this on top of CouchDB<p>The lack of mention suggests the developers either have no clue what already exists, know that their solution can't compete with existing solutions, <i>or</i> don't really care about being better and are just having fun implementing their own system from scratch. None of those answers make me want to take a deeper look.
> It requires zero maintenance and runs on your own infrastructure.<p>I don't understand how these two claims are not contradictory.<p>> All conflict resolution happens locally in each peer using a deterministic algorithm.<p>How exactly does this happen? Via CRDTs? Consensus? How do you handle conflicts?<p>I'm very skeptical about this sort of largely content-free copy fronting what should be a pretty complicated distributed system.
see also <a href="http://kinto.readthedocs.org/en/latest/" rel="nofollow">http://kinto.readthedocs.org/en/latest/</a>