I wrote:
>> <source stream, target stream> -> vcdiff stream
>> <source stream, vcdiff stream> -> target stream
>> What wouldn't this cover?
Branko wrote:
> Well, for one thing, we may want to support different external delta
> encodings someday.
Sure, but is the right answer there to try to convert every delta
encoding to an internal format, or do we just provide different
generation and application functions for each delta encoding?
Karl suggested that generating chained diffs is a good reason for the
text delta data structure. But I'm not sure that's an easy thing to
do with the text delta data structure as currently conceived. If we
have streamy application of deltas, we could certainly apply several
of them streamily at the same time, but I don't think we can easily
combine them into one efficient delta without regenerating the target
stream and generating a new one. (Which can all be done streamily if
you can somehow duplicate the source stream.)
As for what guarantees I want from windows in text deltas, we'll start
with:
* Each window specifies a particular offset and length into
the source data stream. Copy instructions from the source
stream are relative to the window's source offset (or,
alternatively, they must refer to positions equal to or
greater than the window offset).
* Window N+1 cannot have a lower offset than window N.
We also need to deal with copies from the target. Whether a window
can refer to parts of the target string earlier than the part that
window generates is an Issue (tm). vcdiff doesn't allow this, so we'd
have a problem translating text deltas to vcdiffs if we allow this in
text deltas. If we decide to allow this anyway, then each window also
needs to specify an offset into the target (which also can't decrease
from one window to the next) which specifies the earliest position
which instructions can refer to in the target.
Received on Sat Oct 21 14:36:08 2006