Subject: Re: Creating a lock-null in a locked collection

From: Jim Davis <[email-masked]>
Date: Sun, 02 Jan 2000 09:54:46 +0100

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. 

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 may be reading more into the nuances of language than is intended, but
does this mean that WebDAV locks would only be visible at the WebDAV layer
(or perhaps to other protocols that also use URLs) but *not* to other
protocols or APIs that were accessing the same resource?

I would be very unhappy with a design change that asserted that the locks
were only in some "namespace" that only affected WebDAV, or HTTP-based
applications, but not the datastore itself.

I would probably prefer to give up the functionality of BIND than lose the
ability to set locks on underlying resources.

But again, I am not sure that Geoff was actually suggesting this.

regards and happy Y2K

Jim

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Tue, 4 Jan 2000 00:15:56 -0500

From: Jim Davis <[email-masked]>

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 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