Making resources unversioned

At the DeltaV meeting in London, we discussed how to make a resource
unversioned.  We determined that the current method currently proposed in
section 2.2.1 of draft 16  (COPY the latest version of the resource to a new
location, then DELETE the old versioned resource, then MOVE to rename the
new unversioned resource to the old name) is broken, for the following
reasons:
 - It's not guaranteed to work, but not guaranteed to fail if it doesn't
work.
   E.g. the server might automatically create a new versioned resource.  No
way for the client to tell in advance.
 - Log files, permissions, etc. are lost in this series of moves
 - Permissions could prevent the completion of this sequence of events and
leave the documents in a poor intermediate state.  With a single request, a
permissions failure leaves the client in the same state as it was before it
started.
 - basically, it's a side-effect, not a designed behaviour, and relies on
several non-atomic operations working together

We discussed replacing that with the recommendation "delete the VHR to
remove a resource from version control".  This has fewer problems because
it's at least a single atomic request.  However it also has weaknesses, some
of which I didn't remember quickly enough to bring up in the meeting:
 - it could break situations where more than one VCR points to the same VHR,
a scenario which has specifically been discussed as being permitted by
DeltaV.  Would it make all those VCRs no longer versioned?
 - it requires clients and particularly servers to support an entire
optional chapter of DeltaV, and a new resource type with all its live
properties, just to get the ability to remove a resource from version
control.
 - the spec would have to deal with the order of delete operations.  To
delete a resource and all its versions, must the client delete the VHR first
then the now-recently-unversioned resource?  Is deleting the VCR when the
VHR still exists forbidden?

A specific syntax for making something unversioned is still the cleanest way
to go, because when you design a specific syntax for a specific job you're
more likely to be able to make it work.  But in the absence of that, the
draft should at least be brought up-to-date with the most current
VHR-deleting recommendation.

lisa

Received on Saturday, 18 August 2001 01:27:40 UTC