Re: Locking URIs rather than Resources

I think the existing proposals are kind of crufty, because there is no
sensible abstraction that people can understand and expand on.  They either
have the yucky lock-null, or they introduce a new kind of object (a URL)
that is not a resource, the "atom" (basic building block) of web
applications.

Here are the fundamental issues I see:

1) are the list of names in a collection logically part of the collection,
or do they live in some separate space outside the domain of resources?
(I'm using the word name the way jra uses "binding"--the relationship
between a containing collection and a particular resource which is given a
unique name within that collection).

To me the answer must be that they are a part of the collection.  The only
type of object that can be identified within this model is a resource.  You
are going to have (in a real system) access control on resources, and not a
separate access control model for names.  There are too many concepts in the
world of the web to introduce another type of object other than a resource.
Every filesystem in the world stores the list of filenames as a part of the
directory, and locks & access control on the directory affects all names
within.  Let's stick with current usage unless we have compelling reasons to
deviate.

2) what kind of locks are there?

IMHO, there must be two kinds of locks--name locks and resource locks.  The
problem with just locking a collection resource is that it is to
coarse-grained--there are lots of applications that will want to just lock a
single name in a collection, and resource locking every collection in a path
will reduce concurrency too much.  I think of this like table level and row
level locks in a database--a lock on the collection is like a table level
lock, locking all names (rows) in that collection.  Another way to think of
a name is like a fragment within the collection document.

3) what about the notion of a lock "depth"?

There is no such thing.  However, depth may be one way that a protocol
request can specify a particular set of locks.

Now that we understand that, what do we do about RFC 2518 LOCK's?  (I'm
using a capitalized LOCK to distinguish the RFC 2518 protocol request from
name locks and resource locks).

The requirements are:

* a LOCK on must prevent the resource from being moved, for compatability
with existing applications.
* a LOCK on must prevent any changes to that resource (updates, deletes,
etc.) if it exists
* a LOCK token must be associated with the locked resource and URL

So, it seems like that the following solution is the right abstraction:

1) add the notion of name and resource locks.  A name lock applies to a
single level name within a collection.  A resource lock applies to the data
identified by a particular URL.  If that URL identifies a collection, a
resource lock locks ALL of the names in that collection, and is blocked by
any name lock within, and vice versa.

2) we introduce the notion of a lock "set".  A lock set is a group of any
number of name and resource locks.  Each lock set as a single associated
lock token.  An RFC 2518 LOCK request applied to an existing non-collection
resource will grant name locks to each name in the path from the root down
to the bottom, and a resource lock on the identified resource, create a lock
set from this group, and grant an identifying LOCK token.  An RFC 2518 LOCK
request applied to a collection will work in the same way, except that if
the depth header is specified, name and resource locks will be given
recursively for each contained resource.  A LOCK request on a URL giving a
nonexistent name in a existing collection will issue only name locks on the
path elements.  If the URL minus the last path element does not refer to an
existing collection, the LOCK request will fail.

3) the activelocks property displays all name locks active for this
collection as well as all resource locks.

4) the "locktype" property is used to distinguish between name and resource
locks.  If locktype "resource" is specified, only the specified resource
lock is granted in that lock set.  If locktype "name" is specified, the
names from root to the resource are locked, if the Depth header is not
specified.  If the URL "/a/b/c.html" is given, negative depth values can be
given to lock fractions of the path.  E.g. if Depth:0 is specified, the name
"c.html" is reserved in collection /a/b, but no other locks are granted.  If
Depth:-1 is specified, the name "b" in "/a" is also reserved (etc.)  Only if
locktype is not specified does the LOCK request behave as it point #2
(granting resource & name locks simoultaneously), basically for
compatability with existing applications.

--Eric

Received on Monday, 3 January 2000 04:23:06 UTC