RE: Rejected Requirements

At 3:55 AM 5/30/97, Dylan Barrell wrote:
>>7. Only the owner of a lock or a principal with appropriate access rights
>>may remove the lock.
>>
>>8. Only the owner of a reservation or a principal with appropriate access
>>rights may release the reservation.
>
>What is the point of having a lock if it can be revoked by anybody? You
>might as well not bother!

The intent is that "a principal with appropriate access rights" would be a
superuser-like administrator who can remove locks if it is obvious that
they are stale, or if they possess sufficient extra-system knowledge to
know that removing the lock would be safe (e.g., the owner of the lock is
suddenly out sick with a long-term illness).  My expectation is the number
of people who can remove locks will be very small compared to the number of
users of the system.

Within the lock draft submitted to the list last week, the shared write
lock is intended for small groups of people who are collaborating on a
resource and who have sufficient extra-system knowledge to know when it is
safe to write to the resource, even though overwrite errors may occur.

If this possibility of overwrite errors is unacceptable, the exclusive
write lock should be used, which assures only the principal owning the lock
may write to the resource.

However, given that write locks may be removed by administrators, or may
time-out, a safe client should create a precondition using the
"If-State-Match" header (discussed in a separate draft submitted to the
list last week)  on any write operation to ensure that the lock is still
active.

- Jim

Received on Friday, 30 May 1997 14:17:15 UTC