Re: Comments on current version of the WEBDAV spec

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