Our concerns

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