- From: <Tim_Ellison@uk.ibm.com>
- Date: Thu, 8 Feb 2001 10:29:28 +0000
- To: ietf-dav-versioning@w3.org
> Tim, what you've described can make sense, but it leaves > an unspecified hole in the middle. > > If a client does a CHECKOUT then a PUT then a GET, what body > do they see? If we are talking about a checked-in version-controlled resource, say /foo.html, then CHECKOUT /foo --> makes /foo.html a checked-out version-controlled resource, PUT /foo --> updates the content of the checked-out VCR, GET /foo --> gets the content of the checked-out VCR (i.e., whatever you just PUT). If we are talking about a version, say /his/12/ver/3 (and the server supports working resources): CHECKOUT /his/12/ver/3 --> creates a working resource whose URL is returned in the Location: header (say, /wr/45) and leaves the version unchanged, PUT /wr/45 --> updates the content of the working resource, GET /wr/45 --> gets the content of the working resource (i.e., whatever you just PUT), GET /his/12/ver/3 --> gets the content of the version (it will be unchanged by any of this). [Obviously I've left of the http://hostname... from the URLs] > You say "when a version-controlled resource is checked-out, its > C&DP are not necessarily the same as any version." That's not > much of a requirement! Well once the VCR is checked-out it is mutable, so subsequent PUTs and PROPPATCHes will be altering its state. That state is not captured as a version (i.e., in version history) until the VCR is checked in. > It seems I could implement it such that when a client does > a CHECKOUT then a PUT then a GET, they see the body that > existed on the VCR before the checkout. That would contradict the 'you now GET what you just PUT' expectation (requirement?) for a content-bearing resource. > On the other hand, you could implement it so that the same > client does the same CHECKOUT, PUT and GET, and they see > the body that they PUT, which is NOT the body that existed > on the VCR before the checkout. Yep. In fact it need not be the same client. In the example above, other clients GETting /foo can see all the state transitions of the VCR. If you, as a client, want to hide these intermediate states for /foo, then using a working resource would be preferrable. CHECKOUT the version to create a working resource. PUT/PROPPATCH etc the working resource. CHECKIN the working resource to create a new version. UPDATE /foo to the new version. This will result in the VCR at /foo having the same content and dead properties as the new version. > The deltaV draft needs to pick one or another and make a clear > requirement. Tim
Received on Thursday, 8 February 2001 05:33:22 UTC