RE: Comments on current version of the WEBDAV spec

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?

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.

3. I fail to see how turning URLs into commands helps interoperability.

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.

5. The utility of Web Collections is:
	1. A consistent object model.
		This makes content processor's lives significantly
simpler. Rather than having to write a new parser for every conceivable
type of input they can now write a parser one time that can take any web
collection and provide the information in a standard object format of
their choice, ready for processing. We have already implemented web
collection code at Microsoft and will be shipping web collections based
systems w/IE 4.0. Their utility has quickly proven itself as we were
able to take our channel format and quickly get it up and running
because the web collection parsing code was already available.
	2. Automatic Reuse of ideas
		Until now every time a new return format is dreamed up
one has to reinvent ideas such as extensibility, versioning, and so on
all over again. With Web Collections we have the ability to codify
practices such as format versioning, format description, extensibility,
etc. in a standardized, light weight and discoverable way. In fact the
current version of the Web Collection spec uses URIs to specify profiles
so one can literally discover what a collection is and how it works.

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.

7. These are all weaknesses in the draft you read. They should be fixed
in the next major revision.

	Yaron

> -----Original Message-----
> From:	Andre van der Hoek [SMTP:andre@bigtime.cs.colorado.edu]
> Sent:	Tuesday, March 11, 1997 2:14 PM
> To:	w3c-dist-auth@w3.org
> Subject:	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 Thursday, 13 March 1997 23:21:05 UTC