- From: Roy T. Fielding <fielding@kiwi.ICS.UCI.EDU>
- Date: Sat, 15 Mar 1997 08:16:57 -0800
- To: Andre van der Hoek <andre@bigtime.cs.colorado.edu>
- cc: w3c-dist-auth@w3.org
Hi Andre, >My proposal indeed violates the concept of opaque URL tokens; and indeed robs >server of the ability to implement their namespaces. However, on purpose. >Let me try and ask the following question: how does the current WebDAV spec >address the following functionality: I have project X in 4 versions, with a >subproject Y with 6 versions, and a member of that subproject, called Z in 7 >versions. Now I would like to retrieve of version 3 of project X, version 5 >of project Y, menber version 6: i.e.: X -> 3, Y -> 5, Z -> 6. How do I >address this particular entity with the current spec, i.e., with the >versioning links and history resources? The same way you would address any resource -- with a URL provided by the server. The URL is obtained by the client in the same way that any URL is obtained: searching and/or following a link from a related resource and/or cut-n-paste from some other source. If there exists a link from a given resource to one or more project/version history resource, and there exists a link from that resource to the specific version desired, or to some other project/version history resource that directly or indirectly leads the specific version, then there exists a discovery path for any version-specific URL. In other words, you obtain the URL by the same process in which you decided that what you wanted was X -> 3, Y -> 5, Z -> 6, with the only difference being that you are following relationships in a web instead of numbers on an implementation-dependent storage system. >Can I address this entity with the current spec? Yes, assuming you can discover its name. >What is its name? What the server decides to name it, which usually correlates to some aspect of the backend implementation, but which does not correspond to any knowledge inherent in the client. >Can you show me how I carry out this naming? That is server implementation-dependent. More importantly, it is not a protocol issue if the name is always obtained from the server. >If not: it certainly seems to be an important capability to have. I believe it >is currently not possible, but so important and desirable, that I am willing >to violate the design principal. I don't think you did a very good job of explaining why you need it. I can't think of anything in NUCM that would need it, so there is probably something that one of us has overlooked. >If I don't, any server can implement its own >naming scheme, and I lose interoperability, because I can not built a client >that knows about every possible naming scheme. Conclusion: I would like to >standardize on the name space. Attempting to standardize the name space breaks the separation of concerns between client and server, making it difficult to wrap servers around existing resources/gateways, and tying both server and client to features based on the structure of the current namespace. In my experience with versioning systems like CVS, combining versioning and naming is a terrible design decision, since it causes a resource history to break whenever the name is changed. The best solution to this problem is to separate the versioning relationships from the storage of the versions, which just happens to exactly mirror the implementation of a web server with support for non-embedded links. Given that we would like to develop those beasties in any case (for things like annotation and collaborative linking), the most general, and likely to be successful, approach to web versioning is to treat the version history as a collection (DAG) and provide general operations to manipulate that collection, which are then translated by the server into implementation-dependent operations on its own version space. The issue of workspaces is an important one, since it impacts the assumptions that a client can make while working locally (equivalent to the problem of disconnected operation). It should be possible for the WEBDAV protocol to support an application that batches changes into a single commit, even if "support" means just issue a sequence of locks on the affected resources, issue the requests necessary to make the modifications, and then release the locks. However, I should say that I do not know if the current WEBDAV spec provides support for these issues. In fact, since the current spec is not at all current (i.e., I know that many things have changed in the minds of the authors since the last draft), I would be reticent to describe anything within it as "WEBDAV". *hint* *hint* Cheers, .....Roy
Received on Saturday, 15 March 1997 11:21:23 UTC