Chris and I have been sketching out what our queue-sync idea[1] would
look like when run over the CouchDB API. The rough initial writeup is here:
https://wiki.mozilla.org/Identity/CryptoIdeas/06-Queue-Sync-CouchDB
(with some even rougher notes on an etherpad[2]).
It lacks rigor, but should be enough to see where it's headed. The basic
idea is to use couch's "POST _bulk_docs" API (which is used internally
by the CouchDB replication machinery) to deliver batches of new records
to the server, some of which will be accepted, others which will be
rejected (due to other clients delivering their own changes first). We
use the "GET _changes" API to learn about all server changes, both
reflections of our own, and those from other clients. New changes are
delivered to the local Provider (aka engine) for merging into Places.db/etc.
The "Mediator" is responsible for crypto, batching changes into
efficient bundles, all network traffic, and maintains a "revision
table". This table maps locally-generated "content-revisions" to
server-generated "server-revisions", keeping them isolated from servers
and local Providers respectively. These revisions help provide the
previous-version value used by compare-and-swap to reject new records
that aren't based upon the server's previous version (think hg or git
push failing because you aren't up-to-date).
This doesn't use the couch replication system (POST /_replicate), nor
does it embed a copy of CouchDB/PouchDB in the browser. It just uses
couch on the server, and speaks the couch API. This seems like a decent
way to get the benefits of a well-tested API and server implementation,
without taking on the code-size or runtime costs of having a full
CouchDB instance inside the browser.
Let us know what you think!
-Brian
[1]: https://wiki.mozilla.org/Identity/CryptoIdeas/05-Queue-Sync
[2]: https://id.etherpad.mozilla.org/picl-couchdb-queuesync-notes?
_______________________________________________
Sync-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/sync-dev
