W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2001

RE: Notes from DAV meeting

From: Clemm, Geoff <gclemm@rational.com>
Date: Wed, 15 Aug 2001 13:16:05 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B1018E257F@SUS-MA1IT01>
To: Webdav WG <w3c-dist-auth@w3c.org>
   From: Hall, Shaun [mailto:Shaun.Hall@gbr.xerox.com]

   > From: Clemm, Geoff [mailto:gclemm@rational.com]
   > A client holding a lock already has to deal with locks being lost
   > through timeouts.  Allowing another client to effectively force the
   > timeout is a valuable feature that does not increase the complexity of
   > the locking client.  A server can use access control to control what
   > users have permission to force the timeout.

   Supposing the server only supported infinite timed locks (which is
   allowed) and therefore lost locks through timeouts are not an
   issue. You've just bypassed the lock mechanism as we know it. In my
   crude example, what is the original lock creator suppose to do ?

I would strongly advise all client writer to expect timeouts
(assuming you want to interoperate with existing implementations,
such as those provided by Microsoft).  If your lock no longer
exists (either because of a timeout or an explicit unlock by
another client), then your client is responsible for letting the
user know that a write will possibly overwrite subsequent changes.
If the resource is locked by another client, your client should
give the user the option to "save as" at a different URL.  The user
can then look at the two resources (perhaps with the aid of a merge
tool, but often not) to decide whether to merge or just overwrite
the current resource.  In order to update the original resource,
the user can wait until it is unlocked, or if it has sufficient
privileges, it can "steal" the resource back (by unlocking and
then taking out its own lock).

The bottom line is that clients die and leave locks in place on
critical resources.  A server that allows no form of automatic
intervention in this case (either with automatic timeouts, or
with explicit unlock overrides) is unlikely to become very popular.

Received on Wednesday, 15 August 2001 13:07:53 UTC

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