- From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
- Date: Thu, 13 Jan 2000 20:36:25 -0500
- To: w3c-dist-auth@w3.org
Basically, I agree with all of Jim's points. In particular, I'll try out the "lock is on the resource" approach in the next draft of GULP. As Jim noted, in GULP the locking semantics *are* in fact all defined in terms of affect on the states of resources, so the "lock is on a URL" is at best a metaphor. So I'll leave the semantics alone, and just change the metaphor. I'll also modify the way I refer to a lock in the semantics so that it always is in the form of a tuple (e.g. [x, y, z]) so it is clearer when a "lock" appears in the rules. Finally, I believe it is sufficient to say that "lock discovery only displays the locks on WebDAV resources", so that the locks on non-WebDAV collections above the WebDAV are logically there, but you just can't inspect them with PROPFIND. (Jim et. al, does this work for you? Or maybe you can't really say, until you see it written up.) Cheers, Geoff From: Jim Whitehead <ejw@ics.uci.edu> A problem with this proposal (and, to be fair, the same problem is shared by RFC 2518) is it never defines what a lock *is*. That is, there is no sentence here that begins, "A lock is a ...". As a result, this makes it hard to assess whether statements such as the following make sense: "A lock is on a URL. Every lock has a lock token and a lock owner." Good point. I'll add such a statement in the next rev. A WebDAV lock is an abstraction that arbitrates operations on resources. A WebDAV write lock simultaneously guarantees that only the lock owner (or owners, in the case of a shared lock), can write to the resource, and that non-lock-owners are prevented from writing to the resource. Lock ownership in WebDAV is synonymous having the ability to perform the lock-arbitrated operation and unlock the locked resource. WebDAV locks have state, the equivalent to mass and volume for real-world locks. The only description of the state of a lock in RFC 2518 can be found in the lock discovery property, which gives the state of a lock as containing: - lock type - lock scope - lock depth - lock timeout time - lock token - lock owner - lock URL (implicit) For any stateful abstraction, such as a lock, there are several meaningful questions. Is the abstraction a first-class object? That is, is its state and existence independent of other system objects, and does it have its own independent identity? Or is the abstraction a component of some other object. Following the real-world lock analogy, is the lock more akin to a padlock, independent of the items being locked, or a door lock, where the lock is a component of the door. So far in WebDAV, lock state has been part of a resource, since resources are the only stateful objects in HTTP. The GULP proposal, with statements like, "a LOCK request creates a lock on the request URL," seems to imply that lock state is part of a URL. This is a troubling assertion since URLs have not, to date, been stateful objects. But, a further examination of GULP (in the section "a LOCK request creates a lock on the request URL") shows that the lock state is kept on the locked resource's collection, and perhaps on the locked resource as well. Thus the lock is not "on" the URL at all, but is instead on the locked resource's parent collection, and on the resource. The lock certaintly affects the URL, but it isn't "on" the URL. Having the lock state as part of the collection is troublesome, since it implies that only WebDAV resources inside WebDAV collections may be locked. This is an additional (and unnecessary) restriction over anything specified in RFC 2518. Furthermore, duplicating the lock state in the resource and its parent collection seems unnecessary. So, before we proceed, I would like to see a definition of a lock that begins with "A lock is a ...", and I'd like to see a better description of what constitutes the state of a lock, and where this state is kept. Answering these questions will help clarify the rest of the semantics described in the GULP proposal. - Jim
Received on Thursday, 13 January 2000 20:36:29 UTC