> * In fact, I'm not aware of *any* industry-standard binary delta
> format. Hmmm. Probably a deficiency on my part. Does xdelta count
> as industry-standard?
I don't think there's a standard.
> * It's entirely possible that it'll take him less time to implement
> his format than to finish up even the rudimentary vcdiff encoder.
I actually wrote up my format in just a few hours the day after I sent
the proposal. My encoder works and I haven't tested my decoder yet.
I want to set up some more testing and then I'll check it in, and then
maybe hook it up to xml_output.c and xml_parser.c. (Even if we don't
wind up using this format in the end, it gives us something to play
with.)
> * The vdelta paper, besides giving a short (incomplete) description
> of the vdelta algorithm, also describes an encoding format for
> vdelta. It might make sense to take a look at that. see if it's
> useable.
Hey, I had totally forgotten about that. I just went back and looked
at it and it might turn out to be a good choice if my output format
isn't compact enough. One thing I want to look at it just how much
of our output is instructions and how much is new data; if it's mostly
new data, then we want to look for potential bugs in the vdelta
algorithm, but if it's mostly instructions, then we want to see how
compactly we can encode those.
Received on Sat Oct 21 14:36:10 2006