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.

Yes, I of course agree.  My argument here was not that references to
versions can't dangle (obviously they can, if the server allows you to
apply DELETE to the URL of a version.  My argument was just that
"deleting all the versions when you delete the VCR" can be a very
damaging thing, so that it is not behavior that you should leave as
"server defined".  So I'm guessing we've been violently agreeing
here (:-).

   > 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.

   From: John Hall [mailto:johnhall@evergo.net]

   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.
And he is inferring from this that a client needs to be prepared
for references to versions to dangle (which I agree with).
The key sentence is the last one: "It does have to be predictable
however".  I believe this means the protocol has to state what are
the resource deletion properties of a method, and should not
leave it up to the server to decide what deletion semantics it
wants to provide.

   My server WILL allow version delete.

Allowing a DELETE to be applied to a version URL, no argument.
Having a delete of a VCR automatically delete all versions on
one server while having it not delete any versions on another
server, that I would argue against being supported by the protocol
(your server can of course do whatever it wants ... we're just
talking about what behavior the protocol tells clients to expect).

   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.

Surely computer programs are really good at implementing loops? (:-)
Just take the loop that you are using to display the version history,
and replace the display routine with a DELETE request.  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 believe it is unreasonable for DeltaV to assume that no
   client/user/customer would ever want to do that.

I agree.  Which is why explicit version deletion is supported.

   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.  

That I believe is an unreasonable constraint on interoperability with
versioning unaware clients.

   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>.

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.

Cheers,
Geoff

Received on Friday, 15 June 2001 23:27:15 UTC