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