On Wed, Feb 1, 2012 at 00:03, Hyrum K Wright <hyrum.wri...@wandisco.com> wrote: >... > It does require some state to be maintained, but not as much as it > appears at first blush. > > In the current delta editor, we have to keep all these file batons > around, since we need to tie a particular apply_txdelta call to a > given file. If we deal in the currency of hashes, all that state goes > away. The add_file/alter_file callbacks have told us the content they > expect, and we trust that at some future date that content will get to > the destination. > > Because the content has essentially a UUID, we don't need to maintain > per-file state while we wait for it to arrive, we just need a simple > list of things we're expecting, and a way to ensure they get sent. > "Here's the tree; here's the content; I'll let you sort out what > matches to what." Or even "Here's the tree" "Thanks, I need the > following content" "Okay, here's the content you want." > > Does that make sense?
Yup. But it still seems a bit more complicated. I guess this approach means that we could keep a delayed content delivery and not mess around with the commit process, but I do like using the Plan to obviate delivery of certain content streams. Was that your thinking here? (minimal impact to commit) Or is there something a bit more? (and does that benefit outweight the extra checksum/content matching step) Thanks, -g
