Next message: Clemm, Geoff: "renaming "Workspace" header to be the "Target-Selector" header"
Message-ID: <65B141FB11CCD211825700A0C9D609BC01D4D79E@chef.lex.rational.com>
From: "Clemm, Geoff" <gclemm@Rational.Com>
To: ietf-dav-versioning@w3.org
Date: Mon, 20 Mar 2000 13:52:37 -0500
Subject: RE: Disappearing CHECKINs
My point is that many/most clients will not care what the
stable reference to that revision might be. They care what
the value of /foo/bar.html is *now*, and whether it is a
particular revision or a working resource or just a plain
old resource is irrelevant. For the clients that do care,
they can issue the two requests, i.e. PROPFIND to get the
stable URL, and then a GET to get the body of that particular
revision.
Cheers,
Geoff
-----Original Message-----
From: Tim Ellison/OTT/OTI [mailto:Tim_Ellison@oti.com]
Sent: Monday, March 20, 2000 1:47 PM
To: ietf-dav-versioning@w3.org
Subject: RE: Disappearing CHECKINs
The problem is that it means you have to do two requests to the server to
know what GET returned you.
You can't use user's URL twice, e.g.,
GET /foo/bar.html -> get the bytes.
PROPFIND /foo/bar.html -> get the stable reference to the bytes.
since it is not atomic. IMHO there should be some way to get these two
pieces of information in one operation.
The alternative is that clients have to GET the stable URL:
PROPFIND /foo/bar.html -> get the stable reference to the bytes.
GET /my/stable/ref/123 -> get the bytes.
Ditto for other methods.
Tim
"Clemm, Geoff"
<gclemm@rational.com> To:
ietf-dav-versioning@w3.org
Sent by: cc:
ietf-dav-versioning-requ Subject: RE:
Disappearing CHECKINs
est@w3.org
20-03-00 01:07 PM
For existing resources, you can easily find this out with a
PROPFIND, and I'm against trying to "load up" the response to
methods with information just because it might be of interest
to some client. It always seems cheap to add "just this one"
piece of information, but after everyone has added in their
piece of information, request responses become too expensive.
Cheers,
Geoff
-----Original Message-----
From: Tim Ellison/OTT/OTI [mailto:Tim_Ellison@oti.com]
Sent: Monday, March 20, 2000 9:40 AM
To: ietf-dav-versioning@w3.org
Subject: RE: Disappearing CHECKINs
I would go so far as to say that all operations should return the stable
URL of the selected target resource. It is interesting equally interesting
for operations such as PUT and GET.
Tim
"Clemm, Geoff"
<gclemm@rational.com> To:
ietf-dav-versioning@w3.org
Sent by: cc:
ietf-dav-versioning-requ Subject: RE:
Disappearing CHECKINs
est@w3.org
19-03-00 10:55 PM
Yes, I think we did decide to do that. I've updated the spec so
that all operations that create a resource with a stable URL
(such as CHECKOUT, CHECKIN, VERSION) return the stable URL of the
resource in a response Location header.
We do currently have a "current-label" field in the Workspace resource,
but if we take out dynamic version selection, and define CHECKIN to
update a Workspace to select the new revision, we no longer need the
current-label functionality, and I would suggest we remove it since
a client that wants to do this can easily do so with the Location header.
Cheers,
Geoff
-----Original Message-----
From: Tim_Ellison@oti.com [mailto:Tim_Ellison@oti.com]
Sent: Wednesday, March 01, 2000 4:05 PM
To: ietf-dav-versioning@w3.org
Subject: Disappearing CHECKINs
It would seem useful to return the stable URL of resources from a number of
operations, including CHECKIN, since if the revision that was CHECKIN'ed is
not selected by the workspace then it disappears.
A workspace that selects purely on labels for example would be in trouble.
They can't label the working resource, and after CHECKIN the revision has
to be found via the versioned resource revision-set to be labeled.
Tim