RE: Working Resource Issues ...

That is how I would implement it.  But it isn't required, and I could
change my implementation in the future.

Since a Location record is returned with the invisible-checkout, just
like with a WORKING-RESOURCE checkout, there is no reason there
theoretically could not be more than one.  I deliberately said that a
deletion of the URL you were given would undo the checkout that resulted
in the working resource being created, not perform an UNCHECKOUT that
would zap all checkouts.  So a repository that provides multiple
checkouts like this would be advised to count them.

No, I don't see that as a major drawback.  But that is because I'm
developing a simple document server that doesn't allow forking and its
complications anyway.  Not allowing multiple concurrent checkouts is not
an *additional* drawback, and it isn't a drawback at all if you don't
need those features.

I'm not building a versioning repository that could be used in a
diskless workstation environment for software development.  It doesn't
follow that what I am building is useless.



> -----Original Message-----
> From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de] 
> 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 10:58:06 UTC