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

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

   Geoff wrote:
   > 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.

   I'm merely pointing out that in the face of MOVEs you are required
   to use LOCKs to ensure people do not rearrange the namespace under
   your feet.  This is as true today for in-place-checkout as it will
   be tomorrow with CHECKIN&UPDATE.  It will therefore not inhibit
   parallel development any more than it is inhibited already.

Yes, but that's the whole point.  I'd be much more comfortable with
adding a feature if it actually supported something we could not do
today, rather than just "not making make it worse".  Admittedly, not
making it worse is better than some of the other things we're
discussing (:-), but I'd like to raise the bar a bit.  In particular,
with working resources, the server has already gone to the trouble of
allocating a stable URL for the client to use.  All we need to do is
to add a server-maintained DAV:checked-out-vcr property to track the
VCR, and this becomes a *really* valuable feature which allows a
feature to reliably update a VCR without having to lock it.

   I suggest that we provide the operation John requested -- that is a
   CHECK-IN option to update a given version-controlled resource
   (referenced by its URL).  If clients do not want that operation to
   fail due to the version-controlled resource being MOVEd then they
   must LOCK the version-controlled resource.

Then why add the feature at all?  A client can just issue a CHECKIN
followed by an UPDATE and achieve the same result.  These compound
operations do not come for free.  We have to define the results in
case the first part of the operations succeeds (i.e. the creation of
the new version) but the second fails (i.e. the update of the VCR).
Do we make them atomic?  If so, that could be an implementation challenge
since you'd have to make the server "undo" the "create-version" part
of the request, which many servers do not allow (ours, for one, and
we allow you to do virtually anything :-).  If it is not atomic,
then you have to figure out a way to convey back to the client
how much of the operations succeeded.  We're getting all tar-babied
up just to save a round trip.

   <g> Just because I found it unconvincing doesn't mean that I can't
   use it on you and that _you_ also will be unconvinced! <g> (if you
   can follow all those negatives :->

Yeah, well, I was as unconvinced by it the first time as I am now (:-).

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

   Versions cannot MOVE.

Their URL's cannot change, but their underlying physical location does
need to change when distributed repositories are relocated or
multi-sited to other servers.  The same machinery that is used to
track this physical location change is appropriate for computing
the current URL location.  In any case, the likelihood that a
version-controlled resource and its versions are located on a separate
server from the working resources for that version-controlled resource
are pretty slim, even in a distributed implementation.

   > and therefore an additional
   > relationship to track does not obviously add to the implementation
   > burden of such a server".

   Its the nature of the relationship that is different.
   Relationships between server defined URLs will likely be easier
   than those involving user-defined URLs since the server has
   ultimate control over that namespace.

And versions are just one example.  Workspaces and activities can MOVE,
and servers are required to update the properties that refer to them.
The point is that servers can notice when server-controlled objects are
moved, while clients cannot.

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

   I'll tell them to follow the same logic that they follow when any
   resource MOVEs out from under them.  Panic probably.

And you aren't tempted to try to give them some machinery that does
better than that?  And given that the majority of the implementations
will probably not be distributed and be able to maintain this property
basically "for free", wouldn't it be remiss of us not to give them
something better?

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

   The argument is that your way is hard, and it is not what John
   asked for.

Well, I'm still looking for a more convincing argument for why it
is hard (so far all I've got is "Tim said so" :-).  As a counter-
argument, consider the following: every time a VCR is moved, you
inspect the checkout-set of that VCR (i.e. the checkout-set of
every version of that VCR), and update it to point to the new
location of VCR.

Another argument: if a server is supporting the in-place-checkout
option, it will have to update the checkout-set every time a
(checked-out) version-controlled resource moves.  Is it that
unreasonable to have a server that supports the working-resource
option do the corresponding thing for the DAV:checked-out-VCR?

   The simpler solution that I presented is closer to
   John's request and is consistent with the existing client and
   server expectations in the face of MOVEs.

If we are going to burden the protocol with the complexity of a
compound operation (where the "burden" is described above), I'd want
to see more user/client benefit than "saves one round trip".  Similar
response to the "doesn't make the protocol worse than it is now"
argument.

Cheers,
Geoff

Received on Wednesday, 20 June 2001 23:33:20 UTC