On Tue, Jan 31, 2012 at 23:27, Hyrum K Wright <hyrum.wright_at_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
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
> 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"
Sounds yucky, or I'm not understanding your suggestion.
Received on 2012-02-01 07:45:41 CET