Re: locks and trust (Re: Rejected Requirements)

When considering shared locks, there are really two trust sets in
operation.  The first trust set is created by access permissions.
Principals who are trusted have permission to write the resource, those who
are not, don't.  Among those who have access permission to write the
resource, the set of principals who have taken out an shared lock also must
trust each other, creating a (probably) smaller trust set within the access
permission write set.

Starting with every possible principal on the Internet, in most situations
the vast majority of these principals will not have write access to a given
resource.  Of the small number who do have write access, some principals
may decide to guarantee their edits are free from overwrite conflicts by
using exclusive write locks in conjunction with a precondition header
(If-State-Match, perhaps?) that checks for existence of the lock prior to
writing the resource. Others may decide they trust their collaborators (the
potential set of collaborators being the set of principals who have write
permission) and use a shared lock, which informs their collaborators that a
principal is potentially working on the resource.

It is important to remember that the WebDAV extensions to HTTP do not need
to provide all of the communications paths necessary for principals to
coordinate their activities.  When using shared locks, principals may use
any of the following forms of communication to coordinate their work:
face-to-face interaction, written notes (post-it notes on the screen),
telephone conversation, email, ...  The intent of a shared lock is to let
collaborators know who else is potentially working on a resource, so that
one of these communications paths can be used to negotiate writing to the
resource.

So, why not just use exclusive write locks all the time?  Experience from
initial Web distributed authoring systems has indicated that exclusive
write locks are often too rigid.  Researchers working on the BSCW system
initially started with exclusive locks, but relaxed them in later versions.


An exclusive write lock is used to enforce a particular editing process:
take out exclusive write lock, read resource, perform edits, write
resource, release lock.  What happens if the lock isn't released?  While
the time-out mechanism provides one solution, if you need to force the
release of a lock immediately, it doesn't help much.  Granted, an
administrator can release the lock for you, but this could become a
significant burden for large sites. Plus, what if the administrator can't
be reached immediately?

Despite their potential problems, exclusive write locks are extremely
useful, since often a guarantee of freedom from overwrite conflicts is
exactly what is needed.  The solution: provide exclusive write locks, but
also provide a less strict mechanism in the form of shared locks which can
be used by a set of people who trust each other, and have access to a
communications channel external to WebDAV which can be used to negotiate
writing to the resource.

- Jim

Received on Sunday, 1 June 1997 15:01:56 UTC