W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > April to June 2001

RE: Removing a resource: A compromise that satisfies?

From: John Hall <johnhall@evergo.net>
Date: Fri, 15 Jun 2001 13:32:49 -0700
To: "'Tim Ellison'" <tim@peir.com>, <ietf-dav-versioning@w3.org>
Message-ID: <002201c0f5da$5821f530$0400a8c0@xythosjohnhall>
> [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

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:47 UTC