On Mon, Feb 6, 2012 at 12:49, Hyrum K Wright <hyrum.wright_at_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
Received on 2012-02-06 20:27:08 CET