Re: Ev2, RA, Commit Process (was: Editor v2 - suggestions and queries)

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
> 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
Received on 2012-02-01 07:45:41 CET