W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2000

Re: Creating a lock-null in a locked collection

From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
Date: Tue, 4 Jan 2000 00:15:56 -0500
Message-Id: <10001040515.AA17718@tantalum>
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.

Received on Tuesday, 4 January 2000 00:15:59 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:21 UTC