- From: Sankar Virdhagriswaran <sv@hunchuen.crystaliz.com>
- Date: Sat, 19 Jul 1997 18:49:46 -0400
- To: w3c-dist-auth@w3.org
- Cc: spider@hunchuen.crystaliz.com, a4@hunchuen.crystaliz.com
I had said in my earlier message that I would be cataloging our concerns. These concerns were raised during the course of last week's presentation at Utah and we feel that they were not addressed. So, here is a summarization of the issues that we feel need to be addressed. I will summarize the issue, the response we heard, and our reposte plus solution: ISSUE 1 For a protocol that attempts to describe distributed authoring and versioning, there is no description of what version naming scheme *must* be supported. Response Since there are many ways of naming versions, supporting one is not an option Reposte This stops the protocol from supporting inter-operation between clients, proxies, and servers developed from independent sources to inter-operate. Solution There are two ways to go (not mutually exclusive) a) Fix a default naming scheme (e.g., version/branch/version/etc. b) Fix a set of naming schemes and let servers, proxies, and clients exchange this "profile" using PEP ISSUE 2 The current protocol does not allow multiple versions to be active at the same time hence stoping the use of configuration management. And, there is no way to specify that the same version is active in different configurations at the same time. Response: ?? ISSUE 3 The current protocol does not allow the clients to inform the servers the current context (also sometimes refered to as the environment in cooperative transaction processing literature). This prevents us from implementing long term, cooperative transactions on top of the version control mechanism envisaged in WEB-DAV Response: The transaction protocol being worked in W3C and IETF will address this requirement Reposte: Duh! What we are asking for is different. Do we need to explain this or refer you folks to several papers that describe the concept of environments/contexts in cooperative transaction processing. Solution This issue can potentially be addressed by PEP as well as long as WEB-DAV servers, clients, and proxies deal with PEP. ISSUE 4 There are several weeknesses in the current concurrency control proposal which stops us from implementing robust and effcient concurrency control mechanisms. 4.1 When an operation fails, the client has to continuously poll the server to execute that operation again. This increases network traffic. 4.2 The current time-out mechanism assumes that the initiating client is a human (and hence the polling). 4.3 No notion of notification when some action is performed 4.4 While the lock extension mechanism is general there is no standard way to describe the lock mechanisms that are implemented Response: ?? Solution 4.1 There needs to be mechanism by which the client can transfer the data to the server and ask the server to keep trying the operation in a certain frequency or certain number of times. 4.2 We prefer a mechanism that is based on the library reservation model. The duration in which an item is reserved is negotiated (or set by policy). Extension requests can be issued from the client and can be denied by the server. 4.3 Add notification 4.4 Use a standard set of tags that identify different locking policies and use PEP to allow clients/proxies to deal with the "locking" profile intelligently ISSUE 5 Current proposal does not explicitly state the role of proxies in the WEB-DAV protocol Response: The current protocol assumes that all operation except INDEX is dealt by the origin server. Reposte This assumption stops us from implementing distributed, replicated servers that may pre-fetch or cache information for efficiency Solution Two mutually exclusive proposals 1. Spend the time specifying the behavior of proxies (particularly replicating/cacheing proxies) 2. Allow PEP to be used to experiment with approaches that will work for synchronization between replicated/cached copies and when a successful approach is developed add it to the standard ISSUE 6 In the proposal for collection there is no way to determine if a resource is *not* a collection Response ?? Solution Implemnt such an operator ISSUE 7 The current meta data proposal is appropriate for simple file system based version stores that exchange attribute-value pair information, but is not easily extensible for version stores that are databases Response A rich meta data mechanism adds payload and processing requirement for simple version control system Reposte Lacking a formal way for other types of stores to participate results in this protocol being a non extensible system Solution Perhaps have two different tags. One that deals with the current meta data proposal and one that deal with a richer meta data language such as XML-Data or MCF or RDF (whatever that is)
Received on Saturday, 19 July 1997 18:46:10 UTC