Comments on current version of the WEBDAV spec

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