RE: "Lost Updates" still persist

Amen.
	Yaron

> -----Original Message-----
> From:	Judith Slein [SMTP:slein@wrc.xerox.com]
> Sent:	Thursday, February 19, 1998 8:54 AM
> To:	'w3c-dist-auth@w3.org'
> Cc:	Yaron Goland
> Subject:	RE: "Lost Updates" still persist
> 
> If we decide to go the "Implementation Note" route, I would suggest
> something more like the following for the new text.  The idea is to state
> clearly what the problem is, why the protocol can't solve it, and what
> clients and servers can do to help the situation.
> 
> 4.3 Usage Considerations
> 
> Although the locking mechanisms specified here provide some help in
> preventing lost updates, they cannot guarantee that updates will never be
> lost.  Consider the following scenario:
> 
> Two clients A and B are interested in editing the file 'index.html'.
> Client A is an HTTP client rather than a WebDAV client, and so does not
> know how to do locking.
> 
> Client A doesn't lock the document, but does a GET and begins 
> editing.
> Client B does a LOCK, does a GET and begins editing.
> Client B finishes editing, does a PUT, then an UNLOCK.
> Client A does a PUT, overwriting and losing all of B's changes.
> 
> There are several reasons why the WebDAV protocol itself cannot prevent
> this situation.  First, it cannot force all clients to use locking because
> it must be compatible with HTTP clients that do not comprehend locking.
> Second, it cannot require servers to support locking because of the
> variety
> of configuration management systems, some of which rely on reservations
> and
> merging rather than on locking.  Finally, being stateless, it cannot
> enforce a sequence of operations like LOCK / GET / PUT / UNLOCK. 
> 
> WebDAV servers that support locking can reduce the likelihood that clients
> will accidentally overwrite each other's changes by requiring clients to
> lock resources before accessing them.  Such servers would effectively
> exclude HTTP 1.0 and HTTP 1.1 clients.
> 
> WebDAV clients can be good citizens by using a lock / retrieve / write /
> unlock sequence of operations (at least by default) whenever they interact
> with a WebDAV server that supports locking.
> 
> HTTP 1.1 clients can be good citizens, avoiding overwriting other clients'
> changes, by using entity tags in If-Match headers with any requests that
> would modify resources. 
> 
> Information managers may attempt to prevent overwrites by implementing
> client-side procedures requiring locking before accessing WebDAV
> resources.
> 
> --Judy
> 
> 
> 
> 
> Name:		Judith A. Slein
> E-Mail:		slein@wrc.xerox.com
> Phone:  	(716) 422-5169
> Fax:		(716) 422-2938
> 
> Xerox Corporation
> Mail Stop 105-50C
> 800 Phillips Road
> Webster, NY 14580

Received on Monday, 23 February 1998 01:46:36 UTC