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_Ellison@uk.ibm.com>
Date: Thu, 21 Jun 2001 10:18:35 +0100
To: "'DeltaV (E-mail)'" <ietf-dav-versioning@w3.org>
Message-ID: <OF30948E4B.246A46F4-ON80256A72.002FD24C@portsmouth.uk.ibm.com>

"Clemm, Geoff" <gclemm@rational.com> wrote:

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

The feature is to update a version-controlled resource at the same time as
checking in a working resource.  We can't do that today.  Nobody has asked
for a feature to track a moving version-controlled resource, and, although
I agree we cannot do that today, I don't want to introduce unnecessary

(I think it would be useful if the CHECKIN failed if the
DAV:checked-out-VCR's DAV:checked-in property was not the same as the
working resource's DAV:checked-out property, which would indicate you are
about to overwrite someone else's update ... but nobody has asked for that

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

Its only valuable if people need it, otherwise the value is in a simple

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

John stated that he does not intend to support UPDATE, otherwise I totally

> 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 your server supports locks then a simple two-phase approach will work.

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

I'd suggest we do make it atomic.
(Still waiting for that BATCH method...:-)

>    > In any case, the point was not that "those servers are hard to
>    > and therefore it is OK to make them do other hard things", but
>    > that "a distributed versioning server will have to keep track of
>    > relationships between resources on the different servers (e.g. all
>    > 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.

I strongly disagree.  The user's URL references to resources are very
*un*likely to be managed by the same machinery used to track the resources'
physical locations; in the same way that they are not today to achieve
load-balancing, website deployment, and so on.  But we digress.

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

No I'm not tempted since it only solves one particular case (the check-out
of a version-controlled reosurce with an apply to version tag).  There are
so many more cases where MOVE can disrupt the client that fixing it for
this one case is of little benefit overall.

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

I'm not sure why you think the server can maintain this "for free".  It
will make MOVEs very expensive if the server has to update a number of
resources, and will require the server to maintain numerous indices of
these resource dependencies.

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

Ok, you're right.  Provided I can move a resource and update a number of
properties on different resources atomically then I can do this -- and this
is already a requirement for implementing some advanced features of the
specification.  But it makes me *really* nervous to make this REQUIRED
functionality for the working resource feature.  Please keep it simple.

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

As mentioned above, I agree if a server supports UPDATE this problem does
not arise.

Received on Thursday, 21 June 2001 05:19:39 UTC

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