W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2004

Re: PATCH, gdiff, and random-access I/O

From: Jamie Lokier <jamie@shareable.org>
Date: Fri, 30 Apr 2004 10:30:24 +0100
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Justin Chapweske <justin@chapweske.com>, Alex Rousskov <rousskov@measurement-factory.com>, HTTP working group <ietf-http-wg@w3.org>
Message-ID: <20040430093024.GB13899@mail.shareable.org>

Julian Reschke wrote:
> ...for instance, GDIFF requires random access to the old file, while a 
> simpler format may work on plain streams...

That was my immediate concern when I read the GDIFF spec too.
On the other hand, the random access allows fragments of the old file
to be reordered.

Note that traditional "diff" and "patch" also require random access,
because their hunks needn't be in order.

I looked at VCDIFF (which is quite a nice principle).  It does the
same thing: random access is required.  Some attempt to reduce that is
done by allowing the patch to specify "windows" from the old file
which are operated on independently, in sequence.

I must admit I don't like that either: Gzip's sliding window with
bounded length seems, on the face of it, like it would be more
effective at compression (due to increased matching opportunities),
while keeping the access pattern requirements of the
patcher/decompressor bounded to a small region of the stream.

(Gzip also breaks the input stream into blocks, in sequence, but they
are much larger than the sliding window, so much larger than the memory
requirements of the decompressor (which would also be the patcher)).

-- Jamie
Received on Friday, 30 April 2004 05:33:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:49:30 GMT