Next message: Clemm, Geoff: "RE: Pop-quiz"
Message-ID: <65B141FB11CCD211825700A0C9D609BC01D4D799@chef.lex.rational.com>
From: "Clemm, Geoff" <gclemm@Rational.Com>
To: ietf-dav-versioning@w3.org
Date: Mon, 20 Mar 2000 13:07:33 -0500
Subject: RE: Disappearing CHECKINs
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