- From: Yaron Goland <yarong@microsoft.com>
- Date: Mon, 17 Mar 1997 11:29:48 -0800
- To: w3c-dist-auth@w3.org
I would like to apologize for having taken so long to begin this series of postings. The task of putting together my views on how I feel the draft should be changed has taken longer than I expected. My notes are at around 13 pages and growing. The purpose of this series of postings is to stimulate discussion. The ultimate goal, of course, is to get consensus around what the final changes will be. This first post covers the areas of Disconnected Operation, Distributed/Replicated Systems, and Caching. Yaron Disconnected Operation High latency connections, from a 28.8 modem to disconnected operation, are the norm on the Internet. From laptops on airplanes to home computer, users are constantly put into situations where they do not have high bandwidth connections to their servers. As such I propose a litmus test to help the group determine if it has dealt properly with the high latency and disconnected scenarios. If a principal using DAV can disconnect from a network, perform useful work, connect back to the network and using only DAV mechanisms synchronize their state with multiple independent systems on the network, then we have properly dealt with the high latency/disconnected scenarios. Distributed Vs Replicated Documents Distributed System - A system where a group of related resources are potentially available on multiple servers. Replicated System - A system where a resource is available at multiple locations, potentially on different servers. I propose that DAV be required to deal with distributed systems and furthermore that DAV's design make no assumptions regarding the ability of the servers within a distributed system to communicate with each other. Thus if a principal obtains the history of a versioned document there can be no guarantee that the history is complete. Rather the best that can be done is to define the history response format such that it can indicate that additional history information may be available on other servers. This can result in different servers having documents with incomplete, inaccurate, or even conflicting histories, links, attributes, etc. In short, any data that requires cooperation between multiple servers should be seen as suspect. I would additionally propose that unless a server has a mechanism that allows it to reasonably guarantee that the cross server data it is presenting is consistent then all 200 responses should be replaced with something like a 203 response. I say "something like" because the use of 203 for this purpose actually extends the definition of 203 to include the body, not just the headers. As such it may be appropriate to define a new response number. I further propose that DAV only deal with replicated systems that employ a golden copy system. A golden copy is a copy of a resource that is identified as the reference copy. All other copies are referred to as shadow copies. The location of the golden copy of a resource may alter with time but it is required that the involved servers be able to handle transfer of the golden copy without any interaction with the client. Any requests that would alter the state of a resource will be redirected to the golden copy. So if a principal tries to lock a shadow the request will be redirected to the golden copy. Caching Unless specified otherwise, the response from a DAV method is not cacheable. Caches exist to store entities that will remain unchanged for a reasonable time and DAV exists in order to change these entities. However that does not relieve the group from considering caching in the DAV design. HTTP 1.1 caches will purge any response from memory if they see a method executed on the resource that alters the state of the resource. While I could not find an explicit statement to this end, I suspect that most caches will treat any unknown method as a non-cacheable response that requires purging their current responses. Thus DAV methods must assign Request-URIs in such a way as to support this purge mechanism. So, for example, the Request-URI of the COPY method must be the destination of the copy, not the source. That way the cache will purge responses for the destination, which will be changing, rather than the source, which will not. The same logic applies to MOVE so long as the Content-Location header, set to the source, is included in the response, thus causing the source's records to also be purged.
Received on Monday, 17 March 1997 16:58:17 UTC