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 21:23:13 -0700
To: "'Clemm, Geoff'" <gclemm@rational.com>, <ietf-dav-versioning@w3.org>
Message-ID: <000301c0f61c$0ec9fe90$0400a8c0@xythosjohnhall>
> [mailto:ietf-dav-versioning-request@w3.org] On Behalf Of Clemm, Geoff
>    > [mailto:ietf-dav-versioning-request@w3.org] On Behalf Of 
>    Enthusiastic clapping from the audience.
> You may have misinterpreted Tim's message here (or at least, 
> one of us has :-).  When he refers to "version deletion", I 
> believe he is referring to the application of a DELETE to a 
> version URL, not the deletion of versions as a side effect of 
> deleting a VCR. 

We both understood it.

>    My server WILL allow version delete.
> Allowing a DELETE to be applied to a version URL, no 
> argument. 

That is what I meant here.

> Surely computer programs are really good at implementing 
> loops? (:-) 

With versioned properties, there might be a LOT of versions.  No, I do
not want to entertain the thought of all those separate requests.  Not
when it would be simple to allow a flag in the request body.

> And if you end up supporting version history 
> resources (which I believe Lisa was leaning towards, to get 
> "global" properties on all versions of a VCR), then you can 
> just delete the version history resource, and no loops are required.

I'd rather do without global properties than support a VHR, and I
wouldn't want the implementation tied to it.  The problem with global
properties on the VHR is it looks like a proprietary implementation to
me.  (Setting global properties on the VHR wouldn't be, but I would want
to retrieve those properties on any PROPFIND on the VCR or any version.)

> OK, if you can live with the default being <keep-versions>, 
> we are pretty close (I can *only* live with the default being 
> <keep-versions> :-). So the remaining question is: Is that 
> loop through the version history list really so prohibitively 
> complex,  that we need an additional protocol element to 
> optimize it (especially since we already have the 
> optimization that has the DELETE on a version history also 
> delete all the versions in that version history.

It isn't prohibitively complex for the client, it is prohibitively

Without it, I might indeed get forced into supporting a VHR and telling
clients that they have to do a PROPFIND (for VHR) and two DELETE's
instead of just one.  

My other option would be to support the unofficial flag and let my
clients make their own decision about the importance of compatibility.
But a decision like that is above my pay grade.

In fact, I'd probably recommend we do both.
Received on Saturday, 16 June 2001 00:23:14 UTC

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