We should probably think about how we can cover these with the remoteStorage protocol at some point, and maybe talk with the people who came up with that to see if we can merge efforts somehow.
yes! i also talked about that with Dietrich Ayala when i was at Mozilla Portland. he told me we should get in touch with (irc nick) baku about it. i think we can do this in three ways:
consider aligning our baseclient API with their API. they already use promises as well. although there are some differences; they don’t use folders, for instance.
consider using DataStore as an extra local storage option (next to IndexedDB, localStorage, and inmemorystorage). this would have the advantage that you don’t need to have one local store per app, just one local store per device (the same idea as with the idea for a remotestorage.js Firefox extension).
DataStore is journal-like sync (they have revisions and you can replay changes from a certain revisionId.
our sync system is more like a Merkle-tree (https://en.wikipedia.org/wiki/Merkle_tree). We don’t have a real proper Merkle-tree because we don’t enforce that our ETags be cryptographic hashes of the content, and because all ETags are assigned on the central server-node instead of on the node where the content is created, but the idea is definitely similar.
in the DataStore API, each store seems to be just like an array of objects, you can loop over it from object 0 to object store.getLength()-1. we have the path strings as identifiers, which allows richer storing of data into collections (folders), and gives the option to sync only part of the tree.
so i propose not to switch to the DataStore API. i think the space is unexplored and big enough for remoteStorage as well as PouchDB as well as DataStore. next year we can compare notes again and see where all three stand in terms of adoption.