On Mon, Feb 6, 2012 at 12:49, Hyrum K Wright <hyrum.wri...@wandisco.com> wrote: >... >> Yeah, sounds like we're in a tough spot here. The checksums in Ev1 exist >> only as sanity checks -- they definitely are NOT the primary selection >> mechanism for the editor implementation's base text.
Right. This is a key point, and Hyrum's earlier emails adopted a tone of using the base checksum as a key. The real semantic behind that checksum is, "I'm going to send you a delta against some text base that we've negotiated or assumed through an out-of-band communication, and to verify that our communication is correct, that text base should have CHECKSUM." Ev2 gets rid of all that hand-wave magic and leaves deltafication to other layers (notably, RA layers sending stuff over the wire; ra_local will not need to deltify at all). >> I assume we still have a valid checksum to pass to close_file() (the >> checksum of the post-edit fulltext for that file), right? It's just the >> pre-edit base checksum that's the problem? > > Correct. > > r1241097 relaxes the checks by special-casing the checksum of the > empty stream (as discussed elsethread). This addresses the immediate > issue, and I think the generalized case can be punted toward the > individual ra-layers long-term. Note that this will break third-party Ev1 receivers (since they assume something other than the empty stream). You happened to fix *ours*, but not theirs. I think this is the wrong fix, for compatibility purposes. The Ev2->Ev1 shim should have a callback to say "please get me the context/checksum to generate a delta against." If the Ev2->Ev1 shim is ever auto-inserted for backwards compat reasons, then this is breakage. On that basis, I've gotta -1 shipping and using the shim as-is. Using it is a long ways out, so this hack is fine for now and for development. So you've got a long while before it needs to get fixed :-) Cheers, -g
