RE: Baby steps

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