Re: Making resources unversioned

Lisa,

There did not seem to be sufficient support from the working group to 
warrant introducing an unversion method at this time. I can see you 
concerns though, and suggest this would be an appropriate topic to bring 
up again when we move DeltaV from Proposed to Draft standard after there 
has been more implement experience for both clients and servers. In the 
meantime, see the additional comments below where I've attempted to 
address some workarounds for your concerns based on the current protocol.





"Lisa Dusseault" <lisa@xythos.com>
Sent by: ietf-dav-versioning-request@w3.org
08/18/2001 01:27 AM

 
        To:     "DeltaV" <ietf-dav-versioning@w3.org>
        cc: 
        Subject:        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.
<jra>
True, but it might not be as bad as it at first seams. If the copy fails, 
then the system state isn't changed. Note that using a copy explicitly 
allows the user to select which version is to be the unversioned resource, 
not just the latest version. 

If the delete of the history resource fails, then the copy is still there 
creating the new unversioned resource. The move to rename can still be 
done since any VCR that has the same name can be deleted even if the 
history resource wasn't deleted.

If the server automatically creates a new versioned resource, then its a 
server that does not support unversioned resources, or has been configured 
as such. This sounds like the correct behavior.

So the user gets what they wanted, and chances are if a delete of the 
history resource fails, so would an unversion which would have to at a 
minimum do the delete.
</jra>

 - Log files, permissions, etc. are lost in this series of moves
<jra>
Don't know what log files you are referring to, but they would have to be 
server or application dependent anyway. Your server would have to handle 
its own extensions, and clients can easily deal with the permissions given 
the ACL spec.
</jra>
 - 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.
<jra>
Same as the first issue with the same comments.
</jra>
 - 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.
<jra>
In reality, clients already have to support history resources in order to 
support DeltaV semantics. The only thing that's optional is to provide a 
server generated URL for them, and expose their properties. This option 
was included because of one vendor who did not want to have to generate 
the URLs. However, all DeltaV servers have to support generated URLs at 
least for versions, have to be able to support live and protected DeltaV 
properties, and have to provide information on the history of versioned 
resources for the reports. So I don't think support for a history resource 
is adding much burden to a DeltaV server, and the notion of a history 
resource is so fundamental to versioning that I think it should be 
required.
</jra>

 - 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.
<jra>
The delete semantics of history resources may not be something the 
protocol should define. Servers implementations may make it impossible to 
remove all working resources and/or VCRs. Some may not be able to handle 
dangling references in VCRs. Some may choose to disallow the operation 
altogether. This looks like something that will require some 
implementation experience. Since unversion would have to address the same 
issues, we probably should wait to get this implementation experience.
</jra>

lisa

Received on Monday, 20 August 2001 10:53:58 UTC