RE: Last Call for DAV:checked-out-vcr Proposal

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

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.  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, but it is very hard for the *client* to track
these moves, which is why the server should be required to do so.

Cheers,
Geoff

-----Original Message-----
From: Tim Ellison [mailto:tim@peir.com]
Sent: Wednesday, June 20, 2001 9:46 AM
To: 'DeltaV (E-mail)'
Subject: RE: Last Call for DAV:checked-out-vcr Proposal


John Hall wrote:
> In my system I have no problem tracking moves, but it isn't my
> objective.  My objective is having a CHECKIN of the working resource
> update the VCR.  That isn't a 'gee it would be nice to have' request.
> It is far more important to me than that.  Lack of such a feature would
> be quite painful.

I think you may have said this already, so apologies if you did.  Instead of
a new property on a working resource that tracks MOVEs (which I think will
be hard to implement on distributed systems), how about a new CHECKIN option
to do the checkin and version-controlled resource update atomically with a
specific error condition if either cannot be achieved?

I'd be happier with that.

Tim

Received on Wednesday, 20 June 2001 10:19:45 UTC