Re: Comments on current version of the WEBDAV spec

On the risk of this becoming a flame-war which I want like to avoid, let me 
answer here again.  But also, let me ask the rest of the group who is reading 
and paying attention to this e-mail list to also participate.  This is 
absolutely not ment to be a mailing list with few participants (such as until 
now just Yaron and me for this thread), but includes everybody else.  Yaron is 
correct in saying the process is about a concensus.

Now for the answers:

> 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.

I do not understand.  I thought the process was not to have every member of 
the group submit a spec, but to jointly work towards a consensus as you said.  
Part of that is discussing the existing spec, which I am trying to do.  I do 
absolutely not have any intent to write a rival spec.  There are many things 
good about the existing spec, it does not make sense to propose a new one.  
Rather, I would like to improve on the existing one, which is all that I am 
trying to do.  Am I misunderstanding the process now?

> 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.

First of all: apologies for the "Think about it again".  What I ment to say 
was the following: there are issues that are no covered, and I would like to 
challenge you to address and consider these issues.  For example, I do not 
believe that saying "there is some magic that is being used" is the correct 
way to go for our spec, because it leaves issues open.  I did read the spec, 
and did look at the AddResource and RemoveResource commands, and again, do not 
agree with the "magically showing up in a name space" sentence.  What does 
this mean?  What does membership imply?  How do I magically appear in multiple 
name spaces, under different names, but being in reality the same resource?  
Rather than saying "Think about it again", I encourage you to work out this 
scenario with the current spec, and see whether it can be covered or not.  I 
do not believe so, since I can not see a way for this to magically work.  
Thus, I would like to see the spec address this issue in greater detail.

> 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.

But not necessairly WebDAV's view; that was the whole point of my argument.  I 
do not advocate using the cache, I just see it as an intriguing opporunity.  
Rolling out our own cache/workspace is fine with me too, but I believe WebDAV 
should pay attention to it (and you seem to agree as you are talking about 
synch operations, which implicitly say things about a workspace), and 
consequently the spec should be addressing aspects of the workspace.

> 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.

My proposal indeed violates the concept of opaque URL tokens; and indeed robs 
server of the ability to implement their namespaces.  However, on purpose.  
Let me try and ask the following question: how does the current WebDAV spec 
address the following functionality: I have project X in 4 versions, with a 
subproject Y with 6 versions, and a member of that subproject, called Z in 7 
versions.  Now I would like to retrieve of version 3 of project X, version 5 
of project Y, menber version 6: i.e.: X -> 3, Y -> 5, Z -> 6.  How do I 
address this particular entity with the current spec, i.e., with the 
versioning links and history resources? Can I address this entity with the 
current spec? What is its name? Can you show me how I carry out this naming? 
If not: it certainly seems to be an important capability to have. I believe it 
is currently not possible, but so important and desirable, that I am willing 
to violate the design principal. If I don't, any server can implement its own 
naming scheme, and I lose interoperability, because I can not built a client 
that knows about every possible naming scheme. Conclusion: I would like to 
standardize on the name space.

> 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.

I believe that is due to the road taken in this approach.  Larry pointed this 
out in an earlier message: the road taken was one where everything is 
discoverable and everything is interoperable, that is an undauntly difficult 
task. The alternative taken now is to limit the spec to a small number of 
policies, which I believe is a mistake and underestimate of the difficulties 
that arise. In my earlier message I pointed out a situation that for example 
needs to be addressed (non-locking + locking policy interoperating). I think 
that the same problems as before will show up, slightly smaller scale, but 
certainly as hairy. Therefore I am advocating the different approach, also 
laid out by Larry: provide a generic infrastructure to build policies on top 
of. The current spec is actually pretty close to providing such an 
infrastructure, and I believe that eventually in the end this will be the road 
that will be taken and the road that will be more succesfull. Summary: I 
believe that by scaling down the number of policies the spec does not become 
significantly easier, the same old hairy discovery and interoperability issues 
remain.


Do others have any opinions about all of the above?

Regards,

=== Andre ===

Received on Friday, 14 March 1997 18:05:51 UTC