RE: A simpler response ... RE: Working Resource Issues ...

I don't see where you addressed Stefan's question.
Allowing multiple checkouts of the same version is
a key use case.  Limiting this to a single checkout
is supported in an interoperable way by allowing the
server to set the DAV:checkout-fork property to DAV:forbidden.

Cheers,
Geoff

-----Original Message-----
From: John Hall [mailto:johnhall@evergo.net]
Sent: Thursday, June 21, 2001 12:19 PM
To: 'Stefan Eissing'; 'DeltaV (E-mail)'
Subject: A simpler response ... RE: Working Resource Issues ...


There is only one 'in-place-checkout' now, so perhaps we should insist
that any "invisible" in-place-checkout's should be unique.  Therefore,
the only difference is the visibility of the work in progress.

The only reason I made them different URL's is to preserve the semantics
where if you PUT on a resource and then GET you are supposed to GET what
you just PUT.  Therefore, for the PUT's to be invisible it must be a
different URL.

This isn't much different than lock resource, GET, modifing the local
copy, PUT, unlock.



> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org 
> [mailto:ietf-dav-versioning-request@w3.org] On Behalf Of 
> Stefan Eissing
> Sent: Thursday, June 21, 2001 7:20 AM
> To: John Hall; 'DeltaV (E-mail)'
> Subject: 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 16:52:40 UTC