W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > April to June 2001

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

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).

Received on Wednesday, 20 June 2001 11:19:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:47 UTC