This sounds like a pretty interesting research project (I am being
serious here). Its very clever. That having said, why not go with the
simple approach and transfer diffs between trees as I proposed? That
uses known established algorithms and code and is very unclever, which
usually is a good shortcut. I don't see any advantage of Tumblers,
except for being ... well pretty clever.
Andreas
Ryan Kelly wrote:
On 31/07/2013 5:30 AM, Andreas Gal wrote:
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.
* one-document-per-bookmark
[...snip...]
One-doc-per-bookmark has a nightmare to keep consistent in the presence of
mutation, let alone concurrent mutation overlayed with a replication mechanism.
We've talked several times about representing bookmarks in a
one-record-per-bookmark setup with a kind of "materialized path" to
ensure that the tree remains consistent. Rather than using parent/child
pointers, each record would embed its full path and ordering information
via a clever-sounding mechanism called "tumblers":
https://en.wikipedia.org/wiki/Tumbler_%28Project_Xanadu%29
Has anyone written up the details of how this might work?
(I'd offer to write it up myself, but I'm pretty sure I don't understand
all the details)
If this representation works, maybe we get the best of both worlds. If
it doesn't work, it would be good to have a concrete failure case that
shoots it down so that we can move on with confidence.
Cheers,
Ryan
_______________________________________________
Sync-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/sync-dev
_______________________________________________
Sync-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/sync-dev
