RE: Autoversion confusion

This shouldn't be necessary, since the HTTP spec defines the behavior of GET
and PUT. Specifically, it says that PUT to a particular resource defines the
response for any following GET on that same resource (I'm paraphrasing from
memory). There can't be any other possible interpretation (that doesn't
break HTTP semantics).

John

> -----Original Message-----
> From: Lisa Dusseault [mailto:lisa@xythos.com]
> Sent: Thursday, February 08, 2001 1:00 PM
> To: Tim_Ellison@uk.ibm.com; ietf-dav-versioning@w3.org
> Subject: 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 14:28:41 UTC