W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2001

RE: Autoversion confusion

From: <Tim_Ellison@uk.ibm.com>
Date: Thu, 8 Feb 2001 10:29:28 +0000
To: ietf-dav-versioning@w3.org
Message-ID: <802569ED.0039A38D.00@d06mta07.portsmouth.uk.ibm.com>


> 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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:40 GMT