> I need to understand some things about the text delta format:
>
> 1. Why do we need it? (I'm not suggesting that we don't need
> it, but I want to understand why it's there.) Suppose we
> just had functions which did:
>
> <source stream, target stream> -> vcdiff stream
> <source stream, vcdiff stream> -> target stream
>
> What wouldn't this cover?
In the filesystem, I would like to be able to compose a chain of text
deltas. For example, the filesystem may actually store text deltas
for 1.5 -> 1.4, 1.4 -> 1.3, and 1.3->1.2. When the user asks for the
difference between 1.2 and 1.5, I would like to be able to construct
it without actually throwing the text around and recomputing a delta.
This is vague future stuff, though. In particular, notice that the
deltas in the filesystem point from younger to older, but the diffs
the clients will usually want go from older to younger; is it really
feasible to reverse the deltas just using index arithmetic? I don't
know.
This is probably a post-1.0 optimization anyway.
> 2. Do windows within a text delta use restricted portions of
> the source and destination streams for copy instructions,
> or can the operations refer to any location within the
> source and destination streams? It looks like the latter,
> but I don't see how we can apply text deltas streamily in
> that case.
Good point. In order to assure constant-space operation, we need to
impose limits of that sort. The supplier of the windows needs to make
promises to the consumer. But I wasn't sure of the most convenient
way to negotiate such promises, so I left it out of the spec. If you
have reached the point where you know what you want, let's talk
details.
If I remember correctly, all the vcdiff consumers currently in the
system actually have random access to the source string, so as long as
there's some locality in the references in the windows, we're okay.
Received on Sat Oct 21 14:36:08 2006