On Tue, Jan 31, 2012 at 23:27, Hyrum K Wright <hyrum.wri...@wandisco.com> wrote: >... > One of the purposes the "commit plan" could accomplish is establishing > a priori what content the server has, and what content we need to > send, identified via sha1. Thus, if a commit is something like a > merge, where most of the content is already on the server, the client > doesn't have to transmit that information again. (Though maybe this > is already served by the lazy-load semantics of the Ev2 contents > streams.)
Ah. Right. Forgot about that part. Yes, the server can say "don't send C1, C2, C3 to me". Typically, that list will be empty, but sure: sometimes we can save delivery of content. Also note that the list of checksums [to not send] needs to be preserved from Step 1 to Step 2 of the commit process. Some sort of stateful commit process object needs to be carried between the two RA steps. > Another (complimentary?) approach might be to totally divorce content > from structure. Just remove contents streams from Ev2 completely. I'm not sure that I like this approach. That goes back to the "save state across two API invocations" that we had before. It also means every Ev2 receiver will need to have some out-of-band way to receive the content or manage an interaction with a "checksum to content" mapping subsystem. Sounds yucky, or I'm not understanding your suggestion. >... Cheers, -g
