- From: Andre van der Hoek <andre@bigtime.cs.colorado.edu>
- Date: Fri, 14 Mar 1997 11:48:13 -0700
- To: Yaron Goland <yarong@microsoft.com>
- cc: w3c-dist-auth@w3.org
Ok, let me answer here as I believe my points have been misunderstood. > 1. Rename and replace are meaningless operations in URI space. How does > one rename http://blah to http://foo? Is that a rename? A move? A > replacement? Translated: "No!". Well, that is not quite true. Given the addition of collections to the spec (collections, not Web collections), multiple collections can point to the same URL (same artifact), one would like to have the capability to refer to the same artifact under a different name from two different collections. Hence the rename capability. This is not move: I do not do anything with the contents of the URL, and it is not replace for the same reason; I am simply changing its name. A very common capability in versioning systems. Think about it again. > 2. The HTTP Cache is meant to provide support for caching entities which > will be static for some reasonable period of time. Clearly editing > documents does not fit this scenario and thus does not fit the HTTP > cache design. It is up to the client implementers discretion to provide > a reasonable cache. However, tomorrow, I will be proposing extensions > to the diff and other methods to support synch functionality. That way a > client can download an entire area of a site and then, when on-line, > synch up again. Translated: "No!". But, I read in your answer though that workspace will be supported by your extensions, so the answer was "Yes", but not through standardizing of the existing mechanisms. That is fine with me, I just wanted to point out that workspaces are necessary, and proposed a possible implementation of this piggy-backing on an existing mechanism. Your synch functionality will have to now build its own workspace mechanism as opposed to reusing, don't know whether that is wise. Given that WebDAV has already punted several other mechanisms on the Web, the cache is another one that could reasonably be thought of to slightly change the definition of. > 3. I fail to see how turning URLs into commands helps interoperability. Translated: "No!". But...., interoperability was only one of the points that I made and you should read the argument again. I argued that it is going to be necessary to directly address artifacts, without having to go back and forth through collections. This becomes especially true when collections are versioned. There is currently no naming scheme in place in the spec to "walk" versioned collections, i.e., to send a URL to a server and have it interpret the given path with versioned similar to the way a server now interprets a non-versioned path by walking down directories, thus people will choose their own naming scheme thus chances are different naming scheme's will develop. All I said to avoid this was "standardize on a naming scheme"; I never said turn URL's into commands. I propose to set a standard naming scheme to address versions of collections that are not at the tip of a URL, as I believe this capability is necessary. > 4. I do not understand how your proposal scales or addresses the already > existing needs of DAV's members. However the goal of simplification is > something we all share. Both Jim Whitehead and I, independently, will be > proposing our own full featured versioning models. This will involve > choosing a system and running w/it because the advanced features are > needed right now. Translated: "No!". I might be able to agree here, but.... my comment is that the current WebDAV spec is not generic enough, and only accomodates a very limited set of policies; I argued that WebDAV should consider making the spec more generic, and have not heart an argument why it should not. For example, the scheme underlying NUCM can not be expressed using the current WebDAV spec, but NUCM is definitely a distributed authoring and versioning system. I would like to be able to leverage of WebDAV, but its limited generism does not allow me. All I did in my e-mail was proposing changes to the spec that would allow me, as a DAV member, to leverage of the spec. Why is this being denied? > 6. The locking syntax is designed to be easily extensible. The reason > only write locks are included is because the authors, after consulting > w/the group, have come to the conclusion that right now all we need is > write locks. I would address your particular argument but, well, I don't > understand it. If you could please restate I will see if I can satisfy > your concerns. If I can not and if the group still decides that only > write locks are needed then you can always use our extensible syntax to > produce your own RFC which provides read locks. That is the reason why > we choose an extensible syntax. Translated: "No!". Let me thus restate my argument as follows: does a write-lock disallow reads or not? The spec does not say anything about this. So, if I happen to own a write-lock on a large large resource, and am in the process of writing the contents I will be happy, but now someone else comes along with a very fast connection and attempts to read the resource. If the read can succeed (does the write-lock prevent it?) it is possible this person finishes reading the resource before I am done writing the resource, and the person ends up with an incomplete artifact. If I was this person, I would be very unhappy discovering this down the line..... Thus: if a write disallows reads, that should be said. If it does not: read-locking should be included. Additionally, rereading the spec and locking, I think there are issues that need to be resolved with respect to the interaction between locking and versioning. If I am not using locking but using an intent-to-modify, someone else can come along and lock an artifact and make modifications. The effects and interchange of modifying artifacts with these two different policies are not addressed in the current version of the spec, but should. WebDAV is ment to be generic, and to allow a limited set of policies; but does not address the interplay of the various policies. This should be done I believe. Finally, a comment about the comments. I think the answers I got to my suggestions were extremely negativistic, and basically dismissed everything I said. WebDAV is *not* a simple protocol, and the introduction of collections into the spec has many implications that are often not immediately clear, and sometimes stay hidden for a long long time (and it is not just the collections that create a complicated spec). The spec is currently an Internet Draft and actually invites people to submit comments and suggestions. I am providing you with comments and suggestions, and punting me off and saying "go write your own RFC if you don't like this one" is incorrect. I believe I am as much a DAV member as you, and I believe I have given arguments to include and address certain things in the spec. I certainly do not want this to become a personal issue, but I do believe my arguments should have been taken more seriously, and should have been addressed more carefully than as in the above. Regards, === Andre ===
Received on Friday, 14 March 1997 13:49:21 UTC