RE: Comments on current version of the WEBDAV spec

1. It is generally not a good idea to instruct people as to what they
should do, I would recommend leaving comments like "Think about it
again." out of your responses. Either way, if it so happens that two
different URLs point to the same resource then some magic is being used
on the server side and I don't think DAV wants to get mired in how that
magic would work. However I would encourage you to look at the
AddResource and RemoveResource commands in the current spec.

2.The HTTP cache has been designed toward a very specific end, what you
propose doing would radically alter that design. Furthermore,
implementers such as myself would not use the extensions as we will not
have a wire protocol dictating how we will implement our internal
functionality. It is completely appropriate for HTTP to specify how
public and multi-user caches operate. However once the bits are off the
wire, HTTP's purview ends.

3. I do not see how your solution is any more interoperable than using
versioning links and history resources. I do however see how your
proposal violates the concept of URLs as opaque tokens and robs servers
of the ability to implement and maintain their namespaces as they see
fit. As such I do not feel that a standardized URL scheme for naming
versions is appropriate.

4. For what it is worth, my goal for DAV is not to be the ultimate
generic versioning system. We went down that route and found out we had
an incredibly complex specification that was totally non-interoperable
due to the amount of negotiation involved.

6. The current write lock definition is certainly lacking. However I
believe the intent of the authors was to declare that a write lock
prevents reads.

Your assertion that you are every bit an equal to myself as a member of
DAV is absolutely correct. This is all about consensus. I do not support
your recommended changes. However I am just one person. Even if I did
agree w/you that is only one person. You would still have to build a
consensus amongst the majority of the group.

I should also clarify that the current spec has absolutely no special
status. Any spec submitted to the group will be given equal weight. The
only power the current spec has is that it has proven useful in
clarifying issues and helping the group to build consensus.

		Yaron


> -----Original Message-----
> From:	Andre van der Hoek [SMTP:andre@bigtime.cs.colorado.edu]
> Sent:	Friday, March 14, 1997 10:48 AM
> To:	Yaron Goland
> Cc:	w3c-dist-auth@w3.org
> Subject:	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 15:07:14 UTC