Re: vcdiff generator status?

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?

        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.

For comparison on point #2: in the vcdiff format, instructions in a
window can only refer to a particular part of the source and
destination stream, but vcdiff doesn't intrinsically limit windows to
moving forward within the source file. That is, window 1 could refer
to a source data segment starting at an offset of 100K, and window 2
could refer to a source data segment starting at 0K. So even
disregarding the text delta intermediate, we would need to further
restrict the vcdiff format to be able to apply diffs to streamy
sources.

> 4) Write text delta patch (source stream + text delta stream ->
> target stream)

I'll grab this task and leave you with the others, if that's okay.

Branko wrote:
> - Scan long inserts for byte runs that may make the generated
> vcdiff smaller;

I don't think this will help; inserts shouldn't contain any byte runs
of significant length. The vdelta block copy generation algorithm
will typically generate something like the following for a byte run:

        INSERT aaaa
        COPY <length of run minus 4>, <current position minus 4>

Converting this to a RUN instruction would save a little space, but
it's not quite as easy to recognize.
Received on Sat Oct 21 14:36:08 2006