AW: Working Resource Issues ...

John,

if I understand your proposal correctly, one user could not
have two working resources of the same version resource, since
there is only a single URL to access it. Correct?

Wouldn't that be a major drawback for a versioning repository?

Stefan

> Von: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]Im Auftrag von John Hall
> 
> "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:20:26 UTC