W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 1998

Re: Versioning goals doc

From: John Stracke <francis@netscape.com>
Date: Mon, 28 Sep 1998 13:47:22 -0700
Message-ID: <360FF5DA.6F1CDB14@netscape.com>
To: WEBDAV WG <w3c-dist-auth@w3.org>
"David G. Durand" wrote:

> The second is to point out that any object stored in a computer can be
> treated as a sequence of octets, and changes to those sequences are
> _always_ a possible, if sometimes far from optimal, way to represent
> changes.

Yes, you can come up with a format-blind diff syntax.  However, I'm not convinced
you could use such diffs for change-set versioning.  The problem is that,
although you can generate a diff from A to B, and then apply that diff to A to
get B (or vice versa), you can't necessarily compose those diffs arbitrarily
(which, as I understand it, is the goal of change-set versioning, right?).

Let's take an example.  Suppose you've got an image stored as a GIF; let's say
it's a picture of Mickey Mouse's head (the standard frontal view that they show
at the beginnings of the old cartoons).  You've got three different changes you
want to apply: A is "make his ears blue", B is "make his pupils smaller", and C
is "make his chin pointier".  Now, you can take the image and edit it for each of
these changes, and you can get a diff for each of them (call them dA, dB, and dC)
by saving the image back as a GIF.  But you probably cannot compose dA and dC to
get a Mickey with blue ears and a pointy chin, because the binary contents of the
diffs are dependent upon the compression--the bits that dC changes are affected
by the bits that dA changes (at least potentially).  If you can't compose them,
you might as well be using revision-based versioning.  (Or am I missing

Now, it is probably true that, for any given format, you can define a diff
protocol that can be composed.  For GIF, you would render the image as a pixmap,
and diff the pixmap; diffs would then be applied to pixmaps instead of raw GIFs.
(For JPEG, it'd be even easier, 'cause you could probably base it on
off-the-shelf protocols like MPEG, which uses diffs for most frames.) Given this,
you could define a framework which would let you register a diff protocol for
each MIME type (along with a "can diffs be composed" flag); types without a diff
protocol would default to binary diffs, unable to be composed.

Hmm.  Hmm-hmm-hmm.  This might work, actually.  A revision-based versioning
server would represent itself as a change-set versioning server with no diff
protocols other than the default.  It wouldn't need to implement the parts of the
protocol to compose changes (other than to report an error), because it wouldn't
have any composable changes.

|John (Francis) Stracke    |My opinions are my own.|S/MIME supported |
|Software Retrophrenologist|=========================================|
|Netscape Comm. Corp.      | You buttered your bread, now lie in it. |
|francis@netscape.com      |                                         |
Received on Monday, 28 September 1998 16:47:24 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:18 UTC