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 21:47:47 +0100
To: "'DeltaV \(E-mail\)'" <ietf-dav-versioning@w3.org>
Geoff wrote:

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: 20 June 2001 18:31
> To: 'DeltaV (E-mail)'
> Subject: 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.

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.

Just to be clear, if I do an in-place checkout of a version-controlled
resource, and you MOVE it, then my subsequent PUTs will fail and I will have
no indication of where the version-controlled resource was MOVEd.  If I want
to prevent that I must be pessimistic and LOCK the version-controlled

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.

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

Sorry, I didn't mean that will occur because of an UPDATE, rather that that
situation will occur when clients attempt an UPDATE of a URL that has been
MOVEd by another client.  They *will* be told  "sorry, that VCR you wanted
to update is somewhere else, but I won't tell you where"

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

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

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

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

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

Yes.  {At this stage you have to imagine me pointing}

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

Well, 6.6 is easily explained in terms of workspace containment, so that's a
different kind of beast.

13.9 is going to be a real pain to people.

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

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

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

Received on Wednesday, 20 June 2001 16:47:50 UTC

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