Re: a Grand Unified Locking Proposal (GULP, or perhaps, GULP! :-)

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

AltStyle によって変換されたページ (->オリジナル) /