Re: Text delta interface

Jim Blandy wrote:
> Perhaps there is some common case that I'm misunderstanding, but
> concatenating the source and target seems to me more obscure than
> significant. Maintainability is more important.

I couldn't agree more!

> But that's just the way the scales happened to tip for me. If you
> prefer doing things otherwise, that's fine.

I'm aware the arguments go both ways. I just want to make sure we're
all on the same wavelength.

> I don't think it will make streaming more or less difficult. The
> vdelta algorithm must process the entire source string before
> producing its first opcode anyway. But the person writing the delta
> generator is in the best position to answer that question.
>
> Would you prefer an interface closer to vdelta/vcdiff, in which there
> are only two opcodes, one of which copies from the virtual
> concatenation of the source and the target strings? If that's easier
> to work with, then I think it's fine to change the interface.

No, let's keep the interface as it is; it's clear and simple.
I'm seeing vcdiff as an external representation, and there's no reason the
internal form should match it exactly. It's the job of the conversion functions
to do any optimisations that seem necessary, including the overlapping copy.

Anyway, unless I've completely missed something, an overlapping copy will
reduce the delta by one opcode. That's not something we need to care about
right now.

> We're going to ditch glib presently. We're not using it.

O.K.

    Brane

-- 
Branko Čibej                 <branko.cibej@hermes.si>
HERMES SoftLab, Litijska 51, 1000 Ljubljana, Slovenia
voice: (+386 1) 586 53 49     fax: (+386 1) 586 52 70