- From: Jim Whitehead <ejw@ics.uci.edu>
- Date: Thu, 6 Aug 1998 10:00:46 -0700
- To: Bruce Cragun <BCragun.ORM2-1.OREM2@gw.novell.com>, WEBDAV WG <w3c-dist-auth@w3.org>
Comments below. > -----Original Message----- > From: Bruce Cragun [mailto:BCragun.ORM2-1.OREM2@gw.novell.com] > Sent: Thursday, August 06, 1998 7:21 AM > To: ejw@ics.uci.edu; Sam Ruby; WEBDAV WG > Subject: RE: Baby steps > > > This explanation of VPortals helped me a lot in understanding their > purpose. But it returns me to a question I asked in Redmond: What is > the method for getting an earlier (i.e. not the tip) version of a > document? There are a couple of retrieval cases here: 1) Retrieving a version of a resource where the version identifier and Vportal URL are known (but the exact URL of the version of the resource is unknown) 2) Retrieving a version of a resource where the Vportal URL is known, but the version identifier and exact URL of the version of the resource are not known (i.e., perhaps you want the most recent version before a given date) 3) (for completeness) Retrieving a version of a resource where the exact URL of the resource is known. For case 1, ideally it should be possible to use GET, with the version identifier specified in a header, on the Vportal URL. The response will an entity representing the requested resource. Returning to the example from my previous post, if "x.c" is the Vportal, and version 4 of x.c is requested, then a GET request could be made to x.c, with the version identifier "4" specified in a header. The response from the GET will be an entity representing the resource which is version 4 of x.c. For case 2, the version can be retrieved by first requesting a listing of the version graph. The version graph is then examined to determine the version identifier of the desired version. A GET request is then made to the exact URL of the desired version. So, in the "x.c" example, the client would first request the version graph (using GRAPHGET), receiving a list of all the resources in the version graph, their is-derived-from relationships, and their version identifiers. The client examines the version graph for the URL of the desired version, performing a GET operation to retrieve the desired version. Case 3 is trivial -- just perform a GET on the URL of the desired version. For cases 1 and 3, the version is retrievable with a single network round trip. All retrieval cases work for non-tip resources (as well as for tip resources). > And does WebDAV truly support not only getting a non-tip > version but also the ability to return that version, with changes, to > the same location? Stated another way, can I edit a non-tip version > and return it to the collection as that same version, or does WebDAV > force a new version for any change? At present, the consensus of the group, reflected in section 5.9.1 of RFC 2291, "Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web", is that versions, once they are frozen, are immutable. Most working group members I have talked to have been associating "freeze" semantics with the "checkin" method. Based on this, the current versioning proposal would not let you modify an existing member of a version graph (that is, modify the contents available at a given URL), since the members of the version graph are frozen. The current versioning proposal does force a new version on each change. > This issue is critical to us at Novell, so I just want to make sure > nobody believes we have placed such limitations into this spec. In previous discussions on this topic, it seemed to me we had determined that the WebDAV LOCK functionality exactly matches the functionality that Novell terms checkout. Also, I know many people on the list view immutability of previous versions as an essential guarantee provided by a versioning system, and lack of such guarantee as a serious diminishment of the value of a versioning system. It would be helpful to me (and to the list as well), if you could give some scenarios of use where previous versions need to be modified (i.e., where immutability isn't desired), so we can understand why you feel this is a critical feature. - Jim
Received on Thursday, 6 August 1998 13:41:24 UTC