I think using /_bulk_docs and /_changes is pretty efficient if the data model puts each item (bookmark, password, etc) in a separate CouchDB document. There's clearly a spectrum here:
* one-document DB, with one giant JSON blob containing all e.g. bookmarks. (I think https://wiki.mozilla.org/User:Gal/SyncDataModel proposes this, at least for bookmarks). This could be compressed and encrypted, and would be pretty dense. But modifications are either horribly inefficient (replacing the entire document for a one-byte change), or require a custom API to apply diffs (which would only work if the record were unencrypted and uncompressed, and I think we've all agreed that we need a solution that works when they're encrypted). Any two changes (even to unrelated bookmarks) will conflict and need merging. * one-document-per-bookmark (what I'm proposing). Each record is uncompressed (not much point) and encrypted. Data-size grows a bit (we pay the per-document overhead on each record). Modifications are fairly efficient (although changing a bookmark title re-uploads the URL too). Conflicts only happen when we get simultaneous modifications of two fields of the same entry. I think we should be very careful to solve the problem we are trying to solve here, not a more general problem we don't care about. As a user, I won't be editing my bookmarks concurrently on two devices with any significant frequency. Even in those cases having a guaranteed consistent hierarchy wins in my opinion. One-doc-per-bookmark has a nightmare to keep consistent in the presence of mutation, let alone concurrent mutation overlayed with a replication mechanism. Andreas _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
