- From: Lisa Dusseault <lisa@xythos.com>
- Date: Fri, 5 Jan 2001 09:48:50 -0800
- To: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>, <ietf-dav-versioning@w3.org>
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 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. 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. 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... ;) Lisa > -----Original Message----- > From: ietf-dav-versioning-request@w3.org > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Geoffrey M. > Clemm > Sent: Friday, January 05, 2001 8:53 AM > To: ietf-dav-versioning@w3.org > Subject: Mutable Versions (was: re-use of version URL's) > > > > From: Greg Stein <gstein@lyra.org> > > As Geoff stated: you can use version-controlled resources, > labels, or > baseline selectors to create human-readable URLs. > > The version resource URL is (IMO) typically private and > does not need to be > readable. Primarily, the URL needs to be *stable* and *persistent*. > > This thread brings to mind a related topic, which has an even more > negative impact on interoperability then weakening the MUST to a > SHOULD, namely "mutable versions". A mutable version is actually even > worse than a server re-using a version URL, because it provides a way > for a *client* to break versioning semantics. > > But I believe the thread on "re-use of version URL's" points out > an interoperable solution to the "mutable version" issue. In > particular, > clients that want mutable versions want to use the same > "name" to apply > to one state at one time, and another state at another time. But > we already have a mechanism for doing this in the protocol, namely > labels. In particular, if a mutable versioning client uses *labels* > to identify versions of interest, then we get interoperability. > When a mutable versioning client wants to "change" the state of a > version, they just create a new version and apply that label to it, > and that *label* then acts as a "mutable version identifier". > > The only thing we are currently missing to make this work, is > to provide > a way for a mutable versioning client to tell a mutable versioning > server that it wants to create a new version as a replacement of > an existing version. But all we need for this is a "label" parameter > to the checkin command, which tells the server which labeled version > this is supposed to "replace" (effectively combining a "checkin" > with a "move label" operation). > > So I propose that we replace the current "mutable version" option > with the ability to specify a label in a CHECKIN request. This gives > us one fewer option as well as significantly improved > interoperability, > while still providing the semantics required by a "mutable versioning" > client and server. > > Any objections? > > Cheers, > Geoff
Received on Friday, 5 January 2001 12:50:00 UTC