RE: Working Resource Issues ...

> 
> The whole point of CHECKOUT-IN-PLACE is to make the 
> modifiable resource visible at the original URL, so that 
> references to that resource see the intermediate states.  So 
> we'd have to supplement the existing functionality, not 
> replace it, and an addition of this kind would need a 
> compelling use case behind it.


I'm talking about a supplement, not a replacement.

The compelling case is that the feature is useful (otherwise you
wouldn't have WORKING-RESOURCE) supports logic that parallels existing
versioning clients (prior art) and is inclusive of the requirements that
companies attempting to implement the spec consider critical.

> ... so it would need to be a 
> really glaring flaw for us to add/change the protocol at this 
> point (deletion is still fair game, though).

How do you determine glaring flaw?  It meets my definition, and the use
case is not unheard of if you are sympathetic to servers that don't want
to support UPDATE.

>    4.1.3  DAV:checkout-invisible
> 
> How do users see "their" checkouts?  We don't want to tie the 
> versioning protocol to some kind of authentication mechanism.

Same way you do for WORKING-RESOURCE -- by responding with a Location
record.

>    4.7: Additional DELETE semantics.
> 
>    A delete on the URL returned by a CHECKOUT Location header 
> will undo the
>    CHECKOUT which created it.
> 
> You'd have to also define how every other HTTP method acts 
> against these "invisible" resources.  What about MOVE, LOCK, 
> COPY?  (This would make even lock-null resources look good in 
> comparison :-).

Well, the spec doesn't define how a checkout-in-place works against
these verbs, either.

MOVE: See 9.7
COPY: See 9.6
LOCK: Locks the VCR.
UNLOCK: Unlocks the VCR.
PROPFIND, PROPPATCH, PUT, GET: see 2518
DELETE: already addressed
Anything not mentioned: behaves as if issued against the VCR.

Received on Thursday, 21 June 2001 18:31:02 UTC