- From: Chris Kaler <ckaler@microsoft.com>
- Date: Mon, 8 Feb 1999 22:52:22 -0800
- To: "'Geoffrey M. Clemm'" <gclemm@tantalum.atria.com>, max@glyphica.com
- Cc: w3c-dist-auth@w3.org
Comments intermixed... -----Original Message----- From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com] Sent: Saturday, February 06, 1999 9:51 PM To: max@glyphica.com Cc: w3c-dist-auth@w3.org Subject: Re: [long] Re: I-D ACTION:draft-ietf-webdav-versioning-01.txt Max: A thoroughly excellent (and excellently thorough) review! I'll respond to them in the context of "draft-clemm-webdav-versioning-00" (mailed a bit ago to this mailing list, and available on the WebDAV web site). This will give a preview of some of the discussions that will take place at the upcoming design meeting. From: Max Rible <max@glyphica.com> My biggest issue with the new draft of the versioning standard is the usage of gibberish temporary URIs where a user might have to cope with them or a system administrator might have to clean them up. I agree. I believe the argument to CHECKOUT, CHECKIN, and UNCHECKOUT should always be a consistent human-comprehensible URL. [CK] This requires then that a checkout token be passed as part of the request. We can do this, but how then is a CHECKOUT different from a LOCK? Are there any actual cases where temporaries are actually required, as opposed to a gibberish token that can be used in relation to a comprehensible URI? I believe the client should not need to be aware of the location of any such temporaries. [CK] Agreed. Clients should hide the protocol from the user model. There is a certain utility to having the magic files in a magic directory for ease of implementation-- you know you only have to treat a file in a special way if it's in a special location. In my opinion, if you've already done the necessary work to make MKREF function, the additional amount needed to support checked-out files and configurations going anyplace should be small. I agree. [CK] How then does one quickly discover the defined configurations? Is there a major flaw with the notion of CHECKOUT creating a locked, mutable, non-autoversioned revision that the user holding the lock can mutate arbitrarily until a CHECKIN is performed, at which point the revision's name changes from a placeholder to a version number? I agree with the overall concept, i.e. CHECKOUT creates a mutable resource at the specified URL, but I'd modify the following details: I wouldn't want it to be a "revision" because this places excessive constraints on the mutable resource. In particular, a revision can have only one descendent on a given branch, but you sometimes want to allow a revision to have multiple CHECKOUT's to a given branch (requiring a merge before any CHECKIN after the first). But I don't think that it being a "revision" was an essential part of your point. Also, I would want the "lock" to be optional (I don't think the "lock" mechanism scales well, and want it to be an optional part of the versioning protocol). Again, I believe this is not an essential part of your point. [CK] The lock portion is option in -01. I'm curious as to why you don't think the lock mechanism will scale? (i.e. CHECKOUT /foo/bar.html HTTP/1.1 Host: www.foobar.com ... I'd add an (optional) "Workspace:" header, which you can add to indicate that you are checking out into a non-default workspace (a Workspace is the resource that specifies how revision selection occurs across the entire web-site, via a "revision-selection-rule" property). returns HTTP/1.1 201 Created Location: /foo/bar.html Revision-Id: <opaquelocktocken:rejrei-43343-rereffre> Lock-Token: <opaquelocktocken:rejrei-43343-rereffre> I'd omit the Location header (it's always created at the place specified by the CHECKOUT). The Revision-Id is no longer necessary, since you either are checking out into the default workspace, or you are checking out into a specific workspace. In any case, your workspace determines which version you see, so no Revision-Id's need to be passed in requests or reponses. And I'd just use the LOCK command following the CHECKOUT if I want a LOCK, rather than bundling LOCK with CHECKOUT (I don't believe the frequency of CHECKOUT warrants worrying about an extra LOCK method call in this case). [CK] Very confusing. How did you identify the checkout? You don't have a lock-token and you used the same URL? If you return a reivision-id then it is part of the revision graph by definition. This doesn't make sense. [CK] In order for a lock to make sense, it must be atomic with the checkout. As well, there must be interaction between lock and checkout. That is, Non-versioning-aware clients that use LOCK must be able to block Versioning-aware clients otherwise they will clash and non-versioning Clients will not be able to react. [CK] I also disagree with your premise about locks. I find that people frequently want exclusive locks when they checkout a resource even if they have merge facilities. It is a process issue. and the combination of URI and Revision-Id can then be used for any number of PUT and PROPPATCH operations. I agree (replacing "Revision-Id" with "optional Workspace-Id"). When the user says CHECKIN /foo/bar.html HTTP/1.1 Host: www.foobar.com Revision-Id: <opaquelocktocken:rejrei-43343-rereffre> Lock-Token: <opaquelocktocken:rejrei-43343-rereffre> ... the current version is frozen, given a non-temporary name (such as "1.2.1"), and the lock is released. Yes (replacing Revision-Id with optional Workspace-Id, and making the Lock-Token optional, in case you checked it out without a lock). [CK] I think the Workspace-Id concept is confusing and adds an extra layer of burden on clients. Maybe I just don't get it. If they UNCHECKOUT that URI/revision-id configuration, the revision quietly goes away. Yes (i.e. the "working-resource" goes away). The same thing applies to configurations: do they need to exist in special areas? In draft-clemm-webdav-versioning, configurations have a much more constrained purpose (and definition) than in draft-ietf-webdav-versioning. In particular, they are effectively the mechanism for defining an immutable-revision of a tree of resources (rooted at some collection). They can then be specified in the revision-selection-rule of a workspace to cause the appropriate revisions to appear in that workspace at the appropriate URL's. To illustrate the characteristics of the more constrained definition, I'll answer Max's questions as if they were asked about the more constrained definition. *** NOTE *** Max would not have asked these questions about the more constrained definition ... he would have known the answers given below! But his questions and suggestions are very good for illustrating why the more constrained definition might be preferable. *** END NOTE *** Couldn't they be a part of a user's home directory on a server? Direct references would make it possible to give the illusion of a configuration in your home directory, but now you have issues regarding cleaning up a user's files when moving their home directory from one machine to another or removing it entirely. Like other CM metadata such as a "branch" or a "label", you would not normally expect to find one in your home directory. Is a configuration so different from a collection that it should be treated as a separate sort of entity? It looks like a collection that has a special sort of name (the configuration ID) and holds nothing but MKREF-created links to particular versions of files. This is a read-only collection (it is immutable), and it is just a flat list of revision references, with machine-generated names, e.g. mem1, mem2, mem3. So it's nothing a human would ever directly use to find a revision of a particular resource (but is *is* something that a workspace could use to efficiently find such a revision). (An aside: should it be possible to use MKREF to link to a particular version of a file, allowing the reference to provide the Revision-Id or Configuration-Id header to a client who knows nothing of them?) Are there any fundamental differences that would make it difficult to consider a configuration as a collection with some added rules and functionality? The creation of a configuration is an optimized server-specific operation. Although it always results in a (read-only) collection, its creation and storage will depend on factors that would not allow direct creation or modification by a client. Should configurations be able to contain other configurations, or simply references to them? I can easily see that a configuration's user might wish to partition it when it gets large and cluttered. Yes. [CK] I can see why you would want to have a configuration be based on another, but I don't understand containment. If a configuration is a revision selection or a "thread" selection, then containment makes no sense? I'm thinking of software development solutions: a configuration might represent a project, with subconfigurations containing subprojects. Yes. [CK] So the disconnect is becoming more clear here. In -01, a configuration is viewed a the selection of a revision or a revision thread. In this context, a configuration would not be a project, but the project at a point in time. You'd want automatic inheritance from the core project so any time someone else added a file to the configuration, you got a reference to it. This is something you handle with workspace revision-selection-rules, not with configurations (you can't add or remove files from configurations, a configuration is immutable). A large project with a couple of dozen subprojects would otherwise be a pain to bring into a workspace, unless you had a development tool that dealt with all the repetetive actions for you. Yes. (Direct references to other configurations could be used to provide the illusion of nested configurations, but would require a lot of transactions make the parent configuration and then each child configuration inheriting from the originals.) I'm not quite sure what this means, but I'd probably agree with it if I did (:-). Might there occasionally be call for having non-reference members of a configuration? I could easily see a checkin set that has no other reason for existence than its membership in a workspace. Everything in a configuration is a reference to something else (either a revision or another configuration). To make something be an immediate member would complicate the semantics with no obvious benefit. Regarding the specification of the BRANCH command: Why was the decision made to use BRANCH VER:FHHR4959 HTTP/1.1 Host: www.foobar.com Content-Type: text/html Content-Length: xxxx instead of BRANCH /foo/bar.html HTTP/1.1 Revision-Id: VER:FHHR4959 Host: www.foobar.com Content-Type: text/html Content-Length: xxxx I agree that it should be the latter (except that a Workspace header rather than a Revision-Id should be passed in). I also prefer the method name "CHECKOUT-NEW", since this method is useful for non-branch based servers as well. There has also been a massive growth in the number of available DAV properties. PROPFIND allprop operations may lead to very large responses even with Depth: 1, which would slow down performance for users due to network speeds. It might be worthwhile to add this facet to the open issue ALLPROP_AND_COMPUTED. I believe strongly that defining useful properties should take precedence over any desire that ALLPROP should run fast. I personally would vote to just nuke ALLPROP as a mistake, but as long as clients know to never use it, I suppose it doesn't do that much harm. Regarding SETDEFAULT: why is it specified as sending an XML body? It it seems that SETDEFAULT uri HTTP/1.1 Revision-Id: DAV:none is equivalent to the request with a body and consistent with other usages in the specification. Are there other data that may be used with SETDEFAULT at some point? I believe SETDEFAULT is unnecessary, once you have the notion of a default workspace, and therefore should be removed from the protocol. Cheers, Geoff
Received on Tuesday, 9 February 1999 01:52:34 UTC