- From: John Stracke <francis@netscape.com>
- Date: Mon, 28 Sep 1998 13:47:22 -0700
- 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 something?) 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