- From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
- Date: Tue, 4 Jan 2000 00:15:56 -0500
- To: w3c-dist-auth@w3.org
From: Jim Davis <jrd3@alum.mit.edu> At 05:33 PM 12/30/99 -0500, Geoffrey M. Clemm wrote: > >As an addendum to Yaron's response, I'll note that there is a proposal >that WebDAV locking is better understood as locks on URL's rather than >on resources. I am not sure I understand what "is better understood as" means here. By this, I just meant that in order to make sense out of the locking behavior described in 2518, it is better to think of the lock as being applied to the URL (rather than to the resource identified by that URL). In a simple model where every URL identifies a different resource, this distinction is unimportant (except possibly to make sense of a "lock null resource"). In a model where two distinct URL's can identify the same resource (e.g. as a result of a BIND request), this distinction is very significant. I would like it to be the case that if I have a datastore (file system, an object oriented database, an RDBMS, whatever) that *does* support locking, I can use the WebDAV to set a lock on a resource in the datastore, and expect the lock to actually be set on the resource such that other applications accessing that very same resource likewise see the lock, even if they use a different protocol or API to do so. I agree with JimA's response, namely, that the protection of the state of a resource implied by a URL lock can be exposed and enforced for alternative protocols that access the same resources, but as Eric has pointed out, some locking semantics are much easier for current implementations to enforce. Cheers, Geoff
Received on Tuesday, 4 January 2000 00:15:59 UTC