RE: Autoversion confusion

Tim, you've explained this in email before.  I'm not disagreeing with
your interpretation but the point is that standards need to be
self-contained so that implementors don't need to go read the mailing
list archives to achieve interoperability.  Currently, this behavior is
underspecified.

Here's a proposed addition to section XXX that clarifies how the DeltaV
requires implementations to behave:

"In core versioning, while a VCR is checked out it may be the target of
multiple write operations.  During this period, other clients MUST still
be able to perform read operations on the VCR's URL, and the results
MUST show the results of all the write operations that have been
performed thus far.  (Note: if a scenario requires hiding a
work-in-progress from other clients, the "working resource" option can
be used.)"

Does this accurately reflect your understanding of how things ought to
work? I'm not particularly committed to this language or indeed to this
interpretation but the document must pick one and state it explicitly.

lisa

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of
> Tim_Ellison@uk.ibm.com
> Sent: Thursday, February 08, 2001 2:29 AM
> To: ietf-dav-versioning@w3.org
> Subject: RE: Autoversion confusion
>
>
>
>
> > 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 13:03:35 UTC