SlouchDB2

** WARNING: This is still very much a work in progress. **

This is a rewrite of SlouchDB https://github.com/allenu/slouchdb

SlouchDB2 is a journal-based NoSQL-like, distributed single-user database for Apple-based projects (Mac and iOS).

• It's journal-based in that all changes to objects (adding, removing, modifying properties) are stored as diff commands. A snapshot of the database can be generated by playing back a journal.

• It's NoSQL-like in that it stores arbitrary documents, each which is a set of key-value pairs. The keys are strings and the values are JSON-supported types.

• It's distributed in that each device that contributes to modifications to the database writes to its own journal file. Each device is responsible for maintaining a snapshot of the current state of the database. This database state is not shared; only the journals are shared.

• It's single-user in that because of how the journals are stored and sync'ed, it is not appropriate for multiple users who are able to modify entries simultaneously from different devices. The assumption of this database that only a single user with multiple devices is making modifications to the database. Therefore, there is a low likelihood of conflicts when two devices make a modification to the same object.

The goals of rewriting SlouchDB as SlouchDB2 are as follows:

• Simplify the original implementation. The original was written in a more complex, imperative style in places. Since then, I've moved to writing in a more functional, declarative style, which I find leads to easier to reason about code that is more concise and has fewer bugs.

• Make it easier to use by applications. This generally means targeting the mot common scenarios. The original implementation was more open-ended where it may not have been needed. This contributed to its complexity and also made it necessary to understand the model more than needed by clients.

• Design for performance. The original implementation made use of some caching, but it didn't target common scenarios which would arise out of normal sync scenarios. That is, it did not fully consider that syncing across devices may not be done on a regular schedule, and that snapshots of the database may not have been optimized for this irregular schedule.

• Better documentation overall.