- From: Kaelin Colclasure <kaelin@everest.com>
- Date: Mon, 24 Jan 2000 11:18:40 -0800
- To: "Jim Whitehead" <ejw@ics.uci.edu>, "WJCarpenter" <bill@carpenter.org>, <w3c-dist-auth@w3.org>
----- Original Message ----- From: Jim Whitehead <ejw@ics.uci.edu> To: WJCarpenter <bill@carpenter.org>; <w3c-dist-auth@w3.org> Sent: Monday, January 24, 2000 10:57 AM Subject: RE: timeout types > > Bill Carpenter writes: > > RFC-2518, example in section 8.10.8, and description of > > DAV:lockdiscovery in section 13.8 mention a "timeout type" for a > > LOCK. As far as I can tell, the example doesn't show any kind of > > "timeout type" (particularly the one it says it shows), and I don't > > see a description of "timeout type" elsewhere in RFC-2518. > > > > Perhaps the "timeout type" is a holdover from an earlier draft and > > just needs an editorial cleansing? > > Well, "timeout type" is used slightly inconsistently within the spec. In > section 9.8, which defines the Timeout request header, there is a TimeType > BNF production which describes the syntax of the # of seconds the lock will > last, in addition to having an "Other" production, which is intended to > allow extensibility. So this is one meaning for "timeout type" -- the > TimeType within the Timeout request header. It is this sense of "timeout > type" that is used in section 13.8. Are you familiar with the "Lease" technique which I first encountered in Sun's specifications for Jini? <http://www.sun.com/jini/specs/lease101.html> Leases represent a very intuitive (IMO) approach to addressing issues of resource reservation / locking in distributed architectures. While this particular specification is of course for a Java implementation of the concept, there's no reason the idea couldn't be incorporated into a protocol like WebDAV. > During the creation of the spec., we had discussions about whether to > support different kinds of lock refresh policies, and potentially having the > ability to say whether the timeout was absolute, or could be refreshed by > actions on the resource. In the end, the spec. states that locks should be > refreshed by actions on the resource by the lock owner, but this hasn't been > widely implemented (to the best of my knowledge), since it adds a fair > performance penalty to all operations. There is currently an item on the > DAV issues list "LOCK_REFRESH_BY_METHODS" that suggests the current > SHOULD-level requirement for refreshing the lock timer based on actions by > the lock owner should be removed. However, it is this notion of locks being > refreshed by user activity that results in the mention of "activity-based > timeout policy" in 8.10.8. For all the reasons you cite, and *particularly* because the loosely specified semantics of "implicit" refreshes breed interoperability problems, a lease-like mechanism may be worth investigating. -- Kaelin
Received on Monday, 24 January 2000 14:23:39 UTC