- From: Andre van der Hoek <andre@bigtime.cs.colorado.edu>
- Date: Fri, 14 Mar 1997 16:04:26 -0700
- To: Yaron Goland <yarong@microsoft.com>
- cc: w3c-dist-auth@w3.org
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