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

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

From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
Date: Thu, 13 Jan 2000 20:36:25 -0500
Message-Id: <10001140136.AA22895@tantalum>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:53 GMT