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

   From: Tim Ellison [mailto:tim@peir.com]

   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.

One of the key motivators for the versioning protocol is to
allow parallel development, as opposed to single threading
via LOCKs.  A working resource gives you a stable URL to do
your editing against, which means that a namespace lock should
not be necessary for you get your information back to the server.

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

An UPDATE to a VCR does not move that VCR somewhere else (it still has
the same URL).  But that's beside the point ... which is that whatever
operation may have caused the VCR to be found under a new URL, the
server can much more easily track which VCR is associated with the
working resource than the client can.

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

Was that the high-jumping analogy that was used to explain why
a client shouldn't have to do a subset operation?  As I recall,
you found that a less than compelling counter-argument (:-).

In any case, the point was not that "those servers are hard to write,
and therefore it is OK to make them do other hard things", but rather
that "a distributed versioning server will have to keep track of many
relationships between resources on the different servers (e.g. all the
version-to-version relationships), and therefore an additional
relationship to track does not obviously add to the implementation
burden of such a server".

So I'm not saying you are wrong, but that you have not made your case.
For example, can you point to a versioning server today (that supports
the equivalent of working resources) for which tracking this
relationship would be a problem?  I'm not saying there aren't any, but
just that something concrete here would be more convincing.

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

Look at the MOVE request postconditions in 6.6 and 13.9.

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

What did you have in mind for the client to deal with
the consequences?  Tell the user to go find out where
that VCR ended up on the server?

The point here is that a natural semantics of the proposed
protocol extension would solve this use case, so it would
be good to see a convincing argument for why we should not
do so (if we are going to pay the cost of introducing a
new protocol element to handle the "vcr updated by working
resource checkin" scenario).

Cheers,
Geoff

Received on Wednesday, 20 June 2001 13:25:36 UTC