Next message: Geoffrey M. Clemm: "Re: Locking a workspace"
Date: Tue, 30 May 2000 22:41:10 -0400 (EDT)
Message-Id: <200005310241.WAA24516@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: Why do we need working resource ids ?
From: jamsden@us.ibm.com
I think we need to keep uniformity between working resources and
revisions.
I agree (although not so much as to blur their essential difference).
When a working resource is checked out, the request-URL will be for the
versioned resource, and the Target-Selector will select the revision to
check out.
Normally, when you check out a versioned resource, the predecessor
will be the revision currently selected by that versioned resource.
If you want the predecessor to be some other revision, the revision
URL (or label) of that other revision could be specified in the
CHECKOUT request body (no need to introduce a Target-Selector
revision-id header for this use case).
(Note that I think Target-Selector should take a workspace,
label, revision id, etc.).
I disagree, especially the "etc." part (:-). I believe it is sufficient
for a Target-Selector header to just take a label, so that a client
can easily combine a human specified label with a human specified
versioned resource URL.
The return value from checkout needs to be
something that can be applied in the Target-Selector along with the
versioned resource URL (the same one used on checkout) for subsequent
requests. This should be the working resource id.
If we follow Edgar's suggestion (which I believe we should), then the
versioned resource URL would be used to identify the working resource
following a successful CHECKOUT (just as is the case for workspaces).
If you wish to make a "parallel" checkout, then you indicate this in
the CHECKOUT request body, and the server will allocate a new URL for
the working resource, and return it in a Location response header.
Alternatively, if the
client knows the working resource stable URL, that can be used as the
request-URL ignoring the Target-Selector header to access the same
resource. This is the same as for revision selection.
Why would you need the working resource id alternative? Just always
use the working resource URL to identify the working resource. By
default, this working resource URL will just be the versioned resource
URL that the CHECKOUT request was applied to (which is the user defined
URL that a user would prefer to use in any case).
Cheers,
Geoff