RE: Removing a resource: A compromise that satisfies?

> [mailto:ietf-dav-versioning-request@w3.org] On Behalf Of Tim Ellison
> 
> There is always the potential for these references to be 
> broken whenever a server allows a version to be deleted.  
> Where a server allows version deletion the client cannot do 
> that job.  It cannot prevent the client in the next room 
> deleting versions that it considers important.
> 
> Agreed -- I was only stating that, where servers allow 
> version deletion, the proposed condition could be implemented 
> client-side with existing methods -- and since this is the 
> case there is no good argument against it.  It does have to 
> be predictable however.
> 

Enthusiastic clapping from the audience.

My server WILL allow version delete.

I believe it is unreasonable to ask a client that wishes to reclaim
space on the server to do a REPORT version-tree, loop through the
versions, issue separate DELETE's on each version, and then delete the
VCR.

I believe it is unreasonable for DeltaV to assume that no
client/user/customer would ever want to do that.

At this point I'd prefer that a DELETE of a VCR *fail* if the client
doesn't specify <keep-versions> or <destroy-versions>.    I'd rather not
have a default action at all.  

If we do have a default I think it should be <destroy-versions>, because
that is what I think a version-unaware client/user will expect.  But I
could live with the default being <keep-versions>.

Received on Friday, 15 June 2001 16:32:50 UTC