- From: Clemm, Geoff <gclemm@rational.com>
- Date: Wed, 15 Aug 2001 13:16:05 -0400
- 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. Cheers, Geoff
Received on Wednesday, 15 August 2001 13:07:53 UTC