Working Resource Issues ...

"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