On Wed, Feb 1, 2012 at 00:03, Hyrum K Wright <hyrum.wright_at_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
Received on 2012-02-01 07:14:14 CET