RE: locks and trust (Re: Rejected Requirements)

The only point I am trying to make is that shared locks are not really necessary. As far as I'm concerned the difference between what you are describing and what I described is academic. 

Cheers
Dylan

----------
From:  Jim Whitehead[SMTP:ejw@ics.uci.edu]
Sent:  Montag, 2. Juni 1997 19:39
To:  Dylan Barrell; w3c-dist-auth@w3.org
Subject:  RE: locks and trust (Re: Rejected Requirements)

At 10:20 AM 6/2/97, Dylan Barrell wrote:

>
>There are permissions which regulate access to resources.
>Some users have read only permissions and some may add resources or
>overwrite them.
>Those who may add or overwrite resources essentially (as a group) hold a
>shared write lock on the resource.

Well, the view described in the current lock draft is that those who may
add or overwrite (i.e., write) resources all have equivalent access
permission for adding or overwriting a resource.

Of those principals who have equivalent write access permission on a
resource, a shared lock indicates those principals who are, at present,
actively working on the resource.  However, a shared write lock still
prevents non-holders of the lock from overwriting the resource.

This is different from the set of principals who have write access
permission, because it is typically a smaller set.  So, if there are six
authors on a document, they all have write access.  However, if only two of
the authors are currently working on the document, only those two will have
shared write locks (if the authors decided to use shared write locks
instead of exclusive write locks, knowing by their choice that this entails
slightly more communication overhead).

>By adding or removing people from this group (in the broadest sense of the
>word) one can change the membership of the shared lock.

In the example above, it does not make sense to change the access rights
every time an author starts to edit the document.  It makes more sense to
change the access rights only when the set of authors changes.

>Some users have the permission to place an exclusive lock on the resource.
>Only they may then overwrite this resource
>Only they may remove the exclusive lock (admin users excepted)

This is certainly one allowable case.  The drawback to this case occurs
when the principal who has taken out the lock goes home for the day without
releasing the lock, then calls-in sick the next day, preventing their
collaborators from gaining write access to the resource. The other case is:

> Some principals have the permission to place a shared lock on the resource.
> Only they may then overwrite this resource
> Only they may remove their particular shared lock

In this case, if a collaborator forgets to release the lock, other
collaborators can still work on the resource.


Is there some deficiency in the current lock draft?  I believe the
semantics of exclusive write locks and shared write locks are detailed
fairly clearly in this draft.  If this draft is unclear in some way, then
changes need to be made to this draft.

The locking draft can be found at:

http://www.ics.uci.edu/~ejw/authoring/proposals/locking.html

In particular, Section 1.1 describes the difference between exclusive and
shared write locks, and Section 1.2 describes that no locking functionality
is mandatory.  Section 2.2 gives a precise definition of a write lock.
Section 2.7 gives a lock compatibility table which describes interactions
between shared and exclusive locks.

- Jim

Received on Tuesday, 3 June 1997 17:09:15 UTC