- From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
- Date: Fri, 5 Jan 2001 13:26:04 -0500 (EST)
- To: ietf-dav-versioning@w3.org
From: "Lisa Dusseault" <lisa@xythos.com> What you propose makes it impossible for a core-versioning server to implement mutable versioning: the server (and clients!) would have to implement labels as well. A server always had to implement more than core versioning in order to support mutable versioning (mutable versioning was always an option, and one that many, if not most, versioning servers were not going to implement). I agree that there are simpler ways to support mutable versioning than labels, but I do not believe that there is a simpler *interoperable* way of supporting mutable versioning. The difference between the "mutable version option" and the "label option" is that "labeling" is compatible with the other versioning functionality, therefore mutable versioning via labels adds to interoperability, while most of the other options (merging, baselines, activities) are incompatible with the current "mutable version option", and therefore the current form of the mutable version option seriously harms interoperability. A simpler proposal would be just to have an "ismutable" flag that could be queried on any resource. A core-versioning server could treat a CHECKOUT as creating a new version, whereas a PUT without a CHECKOUT would alter the current version. And just as with "re-using version URL's", the result is breaking an key semantic that the versioning protocol provides to clients, namely that the version URL reliably identifies a specific state of a resource. So you are being consistent in supporting re-use of version URL's and mutable versions, but all the arguments for not re-using version URL's apply to not allowing a version to be changed. I would support having an "ismutable" flag in CORE, because it is trivial for a server that does not support mutable versions to set this always to "false", and vice versa of course. This effectively forces every client to be a mutable versioning client, or to refuse to talk to a mutable versioning server. Currently, there are a large number of things a client can do if it can count on a version-URL always reflecting the same content and dead properties. It can cache that information on the client, knowing that it is always up to date. It can request "delta" content updates from the server, by passing in the "version URL" it currently knows about, and having the server just send back the diff between that version and the current content on the server. It can merge, it can save those URL's in dead properties, and all the other points raised on this thread. I've been doing some thinking about his, and I'm about to construct a mail that outlines how mutability is absolutely necessary in some situations, and how human-readable version URLs help out in these situations. Wait for it... ;) Will do, but remember, the whole point of a protocol is to provide interoperability. If you can't count on something being true, an interoperable client just has to assume it's not true. If you can't count on a version URL identifying the same content and dead properties, then you just can't do any of those things that depend on being able to count on that. Notice that none of the other versioning options have this characteristic of breaking things that used to work. If you can version collections, that does not break anything you could count on from versioning leaf resources. If you can baseline collections, that does not break anything that you could count on without baselining. So that's why the introduction states that "these options have been defined to be orthogonal". Unfortunately, this is very much not true about the current mutable versioning option, which if supported seriously breaks a key semantic (some would argue, *the* key semantic) of the core versioning protocol. Cheers, Geoff
Received on Friday, 5 January 2001 13:26:53 UTC