- From: John Hall <johnhall@evergo.net>
- Date: Thu, 21 Jun 2001 07:04:37 -0700
- To: "'DeltaV \(E-mail\)'" <ietf-dav-versioning@w3.org>
"If you remain calm while everyone else is panicking, then you probably don't understand the situation." -- old Naval saying. It appears that some of the long discussion on this topic has been prompted by completely different understandings of what a "WORKING-RESOURCE" is and should mean. I just thought it was a bit-bucket where the user could store his state until he was finished. Check out VCR, get bit bucket, modify bit bucket, Check In. The critical difference between Check-Out-In-Place and Check-Out-Working-Version was the visibility of the bit bucket to other users. In-Place, they can see it. Working-Version, they can't. I've also mentioned that I'm concerned with 3rd party emulation. The 3rd party has a 'working version', and that is exactly how they implemented the concept. That IS NOT what this spec defines. In the post conditions for 9.3 create-working-resource-from-checked-in-version the spec states that "... the version-controlled resource remains checked-in." That is why you have seen two operations when I've only seen one, and need an UPDATE or MERGE. Meanwhile, I'm going "of COURSE the VCR is checked out. I got a successful return on my CHECKOUT didn't I?" I think you should create a new verb (MKWORKING), personally. So how about leaving the WORKING-RESOURCE definition as-is and modify the CHECKOUT-IN-PLACE feature to make invisibility to other users a (REQUIRED) option? I think you will have to finesse a much smaller number of issues if you do that. Since it is required, it doesn't raise the issue of client interoperability. It is new functionality; you can't do what I need to do with the spec defined as is. And by moving it down there you don't confuse the complex 'package' issues Geoff raised. You put it in the basic package, and you don't have clients trying to figure out why they have WORKING-RESOURCE provided but not UPDATE or MERGE. 4.1.3 DAV:checkout-invisible Normally, edits made on a resource while checked out are visible to other users. If checkout-invisible is specified, however, other users will only see the last checked-in version. A client is encouraged to see this feature as "lite" version of WORKING-RESOURCE which leaves the VCR in the checked-out state. 4.2 CHECKOUT Marshalling: If the element checkout-invisible is present, the response MUST include a Location header. 4.6: Additional PUT / PROPPATCH semantics. If a Location header was returned with the CHECKOUT, the URL specified in the Location header MUST be used for PUT and PROPPATCH requests. Otherwise, the server will return cannot-modify-version-controlled-content. 4.7: Additional DELETE semantics. A delete on the URL returned by a CHECKOUT Location header will undo the CHECKOUT which created it.
Received on Thursday, 21 June 2001 10:04:40 UTC