- From: Clemm, Geoff <gclemm@rational.com>
- Date: Wed, 20 Jun 2001 23:38:57 -0400
- To: "'DeltaV (E-mail)'" <ietf-dav-versioning@w3.org>
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