- From: Chris Kaler <ckaler@microsoft.com>
- Date: Tue, 9 Feb 1999 12:35:25 -0800
- To: "'Max Rible'" <max@glyphica.com>, WEBDAV WG <w3c-dist-auth@w3.org>
Comments below... hopefully my mailer won't munge the file like it did yesterday. Sorry about that! -----Original Message----- From: Max Rible [mailto:max@glyphica.com] Sent: Tuesday, February 09, 1999 11:05 AM To: WEBDAV WG Subject: RE: [long] Re: I-D ACTION:draft-ietf-webdav-versioning-01.txt At 22:39 2/8/99 -0800, Chris Kaler wrote: >[CK] In the -00 draft it was proposed that CHECKOUT/IN use the LOCK method > since the behavior is very similar to locks. The working group > decided against this. Note that this style approach would resolve > your issue above as well. Maybe we should model this as LOCK and > return a checkout token as you suggest. This token would then > be passed in on CHECKIN. I guess the question I have then is, > how is this different from LOCK? LOCK gives you a token that may expire at any time for mysterious reasons. CHECKOUT should give you a token that persists until CHECKIN or UNCHECKOUT. CK>> I can take an infinite lock There are a couple of ways to look at CHECKOUT. One is Geoffrey's "A CHECKOUT makes a readonly URL writeable. A LOCK restricts who can write to a writeable URL." In this case, for the usual source control functionality, you would LOCK a resource, then perform a CHECKOUT, and no one else would be able to do anything until you perform a CHECKIN and UNLOCK it. If you simply did a CHECKOUT, *anyone* could write to the resource, and *anyone* could do a CHECKIN on it. CK>> As you point out in the paragraph below, this model doesn't CK>> support multiple checkouts. Note that I do not believe this CK>> is what Geoff meant. He was using a token to distinguish CK>> each checkout. The current proposal for CHECKOUT does not restrict the number of CHECKOUTs against a single resource. The reason I suggested a CHECKOUT token is that you would be able to maintain this functionality if you received a Checkout-Token on doing a CHECKOUT. Any access of a given URL with the appropriate Checkout-Token for the URL will get you the data pertaining to that CHECKOUT-- you can PUT and PROPPATCH using the Checkout-Token all you want, until you perform the CHECKIN. CK>> However, for the case where you need to lock and checkout, which CK>> I would argue is very common even if you take a shared lock, the CK>> client needs to track multiple tokens and include them in the header. CK>> I'm just trying to point out that LOCK and CHECKOUT have very CK>> similar behavior and would be implemented the same in the server. If you have multiple checkouts of the same file, the first person to do a CHECKIN creates the next version; at this point, all other people with CHECKOUTs of the file have to either BRANCH from the version they checked out, perform a CHECKOUT of the new version, UNCHECKOUT the old one, make the changes to the new version, and do a CHECKIN, or apply the new version's changes to their current CHECKOUT and do a CHECKIN with the Override-Checkin header turned on. (This appears to be the behavior in section 3 of the latest document, anyway.) They find out about this when their CHECKIN fails-- presumably with 412 Precondition Failed? 424 Failed Dependency? 409 Conflict? CK>> Exactly. We haven't gotten to the level of selecting the CK>> error condition, although any of the 3 you listed would be CK>> reasonable. >[CK] If they live anywhere in the namespace, getting a list of the defined > configurations is quite hard. That was the idea for putting them > in a "well known" place. Is there a need to get a list of defined configurations? If the header you're passing for a configuration is the URI of the configuration on that server, there's no extra time spent in looking it up. CK>> It is not hard to imagine that a client might want to provide CK>> the user the ability to select a configuration to use. To do CK>> so, it must generate a list. If configurations are anywhere CK>> in the namespace, then you have to search the entire namespace CK>> to produce the list. >[CK] Our idea was that a the /c/Beta1 would contain references to the > resources in the configuration. If a configuration contains > another configuration, how would you represent that? If a configuration is something you navigate into because it is, in itself, a view of a project, it makes sense to have subconfigurations; if it is just a token you pass in so you see a particular version when looking at a given URL, it no longer makes sense to have subconfigurations. CK>> There is still lots of debate here, so let me state this is just CK>> my view. I believe configurations, as defined in -01, serve two CK>> purposes. Dynamic configurations provide a reliable way to select CK>> specific revisions of identified resources. Workspace configurations CK>> provide a way to track changes to related resources. That is, CK>> a branch across a project. In the terms section, we talk about a CK>> thread as a sequence of changes. Workspace configurations are the CK>> related threads of multiple resources. For example, Beta1 of my CK>> project. >[CK] Its clear that we need much more verbage in the document. I'm not sure > I followed the "logging in" part. I'm considering the way that configurations would manifest at a user interface level. At some point, the user needs to tell their software what configuration to use for accessing a server. The choice of configuration would be the equivalent of acquiring an environment when logging in to a machine. CK>> I see. However, I think you can easily switch your "view" of the CK>> the versioning database. If a user is attempting to do work involving two different configurations on the same machine, things could get complicated when persuading their interface to switch back and forth. For instance, consider the case where a project has been BRANCHed after the 1.0 release. One branch is used for bug fixes to the 1.0 code, while the other is used for developing the next 1.1 release. If a bug is found that needs patching in both branches, it should not be immensely difficult for a user to switch back and forth between configurations. CK>> I totally agree. From a protocol perspective, it is as easy CK>> as changing the value of the Configuration-Id header. Another, similar case is the one for two projects that need related changes made-- such as to a WebDAV client and server when a new document comes out from the working group. :-) One configuration exists for the client, and another for the server. Many programmers would implement each feature in turn on the server and the client, testing as they go, rather than implementing them all on the server and then all on the client. If all files remain checked out the whole time, that might not be too hard, but if the programmer does a check-in after each feature has been implemented and tested on both ends, it could be a lot of work to keep switching configurations between the one for the client and the one for the server. CK>> Although they could use a separate configuration to "stage" CK>> the visibility of the change. >What other information would go in with SETDEFAULT? For that matter, is >SETDEFAULT really doing anything you couldn't with PROPPATCH? If I'd read >that SETDEFAULT functionality was to be implemented with a live property >named DAV:defualtversion, I wouldn't have blinked... >[CK] We debated this one for a while. The issue really comes up with > references. Aha. It might be good to explicitly call out references for "If a resource is shared, servers MUST support the ability to set different default revisions at each point of the share." CK>> I thought we did. If we didn't, and I can believe it got lost CK>> in the editing, I'll make sure it is in the next revision.
Received on Tuesday, 9 February 1999 15:35:41 UTC