RE: Autoversion confusion

I wasn't talking only about the client that did the put.  The DeltaV
spec ought to state normatively what OTHER clients experience.  I'll
repeat from my earlier mail, my suggested language:

"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.)"

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: Friday, February 09, 2001 1:58 AM
> To: ietf-dav-versioning@w3.org
> Subject: RE: Autoversion confusion
>
>
>
>
> John wrote:
> > 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).
>
> I agree with John.
>
> At the risk of nagging<g>, a version-controlled resource is
> an honest to
> goodness WebDAV resource, with content and properties
> (version-controlled
> collections have members and properties).  Intuatively, if a
> PUT to the
> resource succeeds (200 OK) then a client is entitled to
> believe they will
> GET the same entity back.
>
> p.s.
> I had a quick look through the HTTP/1.1 spec, and didn't see
> anything that
> states this categorically.  In fact, Section 9.6 (PUT) states:
>  "HTTP/1.1 does not define how a PUT method affects the state
> of an origin
> server."
> Now, how many clients do a GET just to check what they actually will
> retrieve after a successful PUT!
>
> Tim
>

Received on Friday, 9 February 2001 11:17:23 UTC