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

Advisory Locks & DAV:LOCKTYPE Attribute

From: Yaron Goland <yarong@microsoft.com>
Date: Wed, 26 Mar 1997 00:10:18 -0800
Message-ID: <11352BDEEB92CF119F3F00805F14F485026B72C5@RED-44-MSG.dns.microsoft.com>
To: DAV Discussion <davdisc@microsoft.com>
1.	Advisory Locks

1.1	Problem Definition

In a versioning system that exists in an open, collegial atmosphere
where proper behavior can be reliably expected, it is not necessary to
enforce locks. The absence of enforced locks makes the system easier to
administer as there is no more need for frantic phone calls to the
SysAdmin over the weekend because some key file has accidentally been
left locked by an unavailable principal.

However it is desirable to provide a mechanism whereby system users may
determine if someone is currently editing a file and to be able to cause
system changes to only occur if no one is currently editing a file.

1.2	Proposal

I propose introducing a new value for LockType in the Lock-Info header,
"Advisory". The Advisory attribute is used to indicate that the
requested lock is advisory. This means that the system will not prevent
anyone without a lock from modifying the resource. However the client's
intent in setting such a lock is to provide notification of their desire
to modify the resource. As such the server should only accept Advisory
locks if it makes available the DAV.LockInfo header.
Once a resource has an advisory lock placed on it, it is not possible to
place any other type of lock on the same resource. The same logic
applies to ranged locks.

1.3	Discussion

While the matter is still open, we will be providing an if-match and
if-not-match like feature for lock tokens. So it will be possible to put
a header on a request which tells the server "Only process this request
if no one has locked the resource." This isn't needed for exclusive
write locks as the system is required to enforce proper behavior, but it
is necessary with advisory locks.

2.	DAV:LOCKTYPE Attribute

2.1	Problem Definition

Servers may support any number of lock types. These proposals have
already defined two, exclusive write and advisory. As such a mechanism
is needed to find out what sorts of locks are supported on a resource.

2.2	Proposal

I propose introducing the DAV:LOCKTYPE attribute.
This header lists LockType attributes as defined in the proposal on
locks. Each locktype indicates a type of supported lock.
Received on Wednesday, 26 March 1997 03:29:23 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:15 UTC