- From: Tim Ellison <tim@peir.com>
- Date: Wed, 20 Jun 2001 16:19:33 +0100
- To: "'DeltaV \(E-mail\)'" <ietf-dav-versioning@w3.org>
Geoff Clemm wrote: > If we are going to add a protocol element for allowing a CHECKIN > of a working resource to update a VCR, it would seem appropriate > to define this in a way that is friendly to clients (i.e. they > are not required to "LOCK" the VCR namespace, This would be the pessimistic approach, to prevent the MOVE. > and they are not at risk of being told "sorry, that VCR you > wanted to update is somewhere else, but I won't tell you where". That is going to occur anyway with an explicit UPDATE of a version-controlled resource. > I don't buy the "hard to implement" argument, since anyone who is > implementing a distributed versioning system will have to deal with > far more difficult implementation issues than reliably associating > working resources with version-controlled resources. That argument has already been debunked (by Greg and others with their high-jumping analogies :-) > And for the common case (where the working resources and the > version-controlled resources are on the same server), it is not > hard for the *server* to track these moves, On what basis do you say this? We have no other examples of the server being required to track resource MOVEs and I believe that it will require substantial housekeeping for a number of implementations to do this. > but it is very hard for the *client* to track these moves, > which is why the server should be required to do so. I'm not suggesting the client track them either. I think the client should be pessimistic or be prepared to deal with the consequences (as for all other MOVE scenarios). Tim
Received on Wednesday, 20 June 2001 11:19:35 UTC