- From: Andre van der Hoek <andre@bigtime.cs.colorado.edu>
- Date: Tue, 11 Mar 1997 15:13:37 -0700
- To: w3c-dist-auth@w3.org
Hi, some of you may know me, some of you might not, therefore let me briefly introduce myself. I (and several others) are working on a generic, distributed, repository that is specifically targeted towards Configuration Management (or versioning). This effort is called NUCM. As NUCM has similar goals as WEBDAV, I have been somewhat involved in the current WEBDAV spec by privately talking to Jim, and actually attending an authors meeting to help out with the versioning issues. At that moment though, I viewed the WEBDAV spec as out of control, too many features were included without a purpose, and more features were added by the day. I posted our NUCM interface to this mailing list as a counter-example, but did not receive comments. In any case, recently I reviewed the current WEBDAV spec, and I am pleased to see that it has scaled down quite a bit, and I was very surprised to see that the new spec shares many concepts with NUCM. However, there are still some fundamental differences that I would like to point out here and that I believe should be included in WEBDAV as well. These boil down to the following which I will explain in more detail below: 1. Collection support. 2. Workspace support. 3. Naming support. 4. Policy-neutrality/discoverability. 5. Web Collections. 6. Locking. 7. Minor things. 1. Collection support. The current spec is vague with respect to collections. URI's can only be added or removed from a collection, there is no support for renaming or replacing URI's in the collection. Given that these two logically complement the add and remove operators, I believe they should be added. It is unclear whether collections can be versioned. I assume so, but the spec should be more explicit. Finally, the WEBDAV spec says that collections are "fluff with no merit", I believe there is merit: see point 3. 2. Workspace support. NUCM employs a notion of workspace, and caches artifacts at the client side. It subsequently uses this cache to do most of its operations in the cache before submitting changes to the server. It seems almost natural to me to make use of the existing caching techniques present in the WWW, structure the cache, and make use of it to store temporary versions, to store hierarchical workspaces that one can work in, etc. In this way client-server communication is significantly limited. It is just an idea, but I think it should be given careful consideration by the WEBDAV group. The fact that "Working-URI's" are sent back and forth implies already some limited concept of workspace. 3. Naming support. Hot issue, heavily debated at the early stages of WEBDAV, but subsequently put aside. I believe the introduction of collections warrants a reconsideration. Consider the following: I want version 6 of source file A, that is part of the GIU implementation version 4, in project version 3. A completely natural way of addressing this is: project:3/gui:4/source:6 The current version of the WEBDAV spec does not allow this, because the mime-fluff around a URL only allows for specification of the version of the tail of the URI. In other words: it is impossible to walk the hierarchical tree with WEBDAV. In yet other words: WEBDAV says each artifact (even each version of) must be individually addressable, thus, each version of a collection has its own URL. Thus, one can imagine schema's like the one above, but also: project_3/gui_4/source_6 and many others. If WEBDAV is to maintain policy-neutral and fully interoperable, it will have to choose one representation, otherwise servers who version are compatible if they choose different naming scheme's. Doon't answer with "this should be discoverable", I believe an addition to the URL naming scheme that standardly defines how names and versions are part of a URL is very much needed in WEBDAV. It gives us consistency across servers, and above all, the ability to walk collections (versions of collections) in one step, as opposed to step by step with client-server interaction at each step. 4. Policy-neutrality/discoverability. The number of things currently discoverable is limited: versioning and locking. And these are exactly the two that imply a policy that is included in WEBDAV, and there are only a limited set of policies supported; at the authors meeting these were called the "winners", but sure enough, not all of them are winners and not all real winners are included either. I believe a much more neutral interface is needed, that gets rid of the version-tree, and allows simple linear versioning at the base level, and a very simple locking mechanism at the base level (no ranges). This would have the following effect: * Any client can talk to any server, as there is a single protocol; the protocol is completely policy-neutral. * Someone who wants to implement a policy can build its client and server on top of this basic protocol in an quick and easy manner; the protocol would be sufficiently strong to do so. For example, to do check-in/check-out: only a version-tree would have to be build, which is a minor effort. This would completely get rid of the "discoverability" aspect of the spec, and significantly clean it up. In addition, if you do want this kind of functionality, is there no way we could envision the base protocol, with higher level functionality as libraries (that are discoverable....)? 5. Web collections. I am unsure what the role of Web collections in the spec is. First of all, the details are sometimes written in a different BNF in the spec, and second of all, where is the use? Does it really add that much to the protocol? It looks to me like the only time you need them is when you return a collection, but in that case, this could be a simple line-based result: each line one member of the collection. Of course, everything is to some extend a collection in this spec (a set of mime-attributes for example), but to encapsulate them in some new notion called web collections that only puts a fancy <WC> </WC> around them, is overkill to me. The line based results have worked satisfactorily, why something new? 6. Locking. Contrary to the range-locking - no range-locking discussion, I have a different question: currently, artifacts can only be write-locked, but what about read-locks? Writing a 1000K file from one site could be very small, and some other request could come in from a fast connection that requests the same artifact. This could result in just part of the artifact showing up at the client-side, and it seems to me read-locks are needed. 7. Minor things. Some examples would be in place in the spec. I still have no clue what a "DAV/History" would result in, even from studying the BNF. The effects of COPY/MOVE are unclear: is it implied here that a server contacts another server and copies/movers the artifact? How is this envisioned? It is unclear what SERVERMERGE does to the version-tree. Is a new version created? Are links put in place? It seems like some of this needs to be taking place. If not, who does? The client? Which methods allow me as a client to explicitly manipulate the version tree then, i.e., link the result into the version tree as a new branch/version. Also, are "branch" and "merge" relationships maintained in the tree? That is about the extend of the comments, I hope they are useful, and of course I am always willing to discuss. Regards, === Andre === -- ===================================================================== = = = Andre van der Hoek. = = E-mail: andre@cs.colorado.edu University of Colorado at Boulder = = Phone : 303-492-4463 Dept. of Computer Science = = Fax : 303-492-2844 P.O. Box 430 Boulder, CO 80309 = = WWW : http://www.cs.colorado.edu/users/andre = = = = Somebody has to be brilliant, but it ain't me, although I hoped so. = = = =====================================================================
Received on Tuesday, 11 March 1997 17:13:37 UTC