- From: Yaron Goland <yarong@microsoft.com>
- Date: Sat, 28 Sep 1996 12:32:30 -0700
- To: "'ben@algroup.co.uk'" <ben@algroup.co.uk>, "'Jim Whitehead'" <ejw@ics.uci.edu>
- Cc: "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>
We here at Microsoft must have locks without timeouts. This does not mean that we should not implement locks with timeouts. Rather it means there must be a way to specify "This lock has no timeout". As long as that feature exists I am agnostic on the issue of timeouts. Thanks, Yaron >-----Original Message----- >From: Ben Laurie [SMTP:ben@gonzo.ben.algroup.co.uk] >Sent: Saturday, September 28, 1996 3:19 AM >To: Jim Whitehead >Cc: w3c-dist-auth@w3.org >Subject: Re: Lock timeouts revisited > >Jim Whitehead wrote: >> >> At the Cambridge meeting the issue of lock timeouts was discussed. I was >> in favor of having locks which automatically timed-out after a given >> duration, and the remainder of the participants were either neutral, or >> somewhat opposed to the idea. >> >> I'd like to revisit this issue, because discussions I've had about locking >> since have convinced me that lock timeouts are a good thing, and we should >> include them in the functionality we propose. >> >> The compelling reasons for having lock timeouts stem from a consideration >> of what to do when someone has a lock out, and then forgets about it, and >> someone else needs the locked capabiity on the resource. This is a fairly >> common occurrence. >> >> Today, most systems allow someone to become a super user and then manually >> remove the lock. Typically there are enough people around with super user >> capability that removal of locks isn't a big problem. This practice does >> depend on having access to the people with lock removal priviledges. >> >> In a distributed authoring situation, it is likely that lock breaking >> capability will be limited to a very few people. For example, in the case >> of an Internet Service Provider maintaining a web space for hundreds of >> people, it is likely there will only be very few employees of the ISP with >> lock breaking capability, and they will not want to be bothered with this >> activity. >> >> Thus there is a need for a way to decentralize lock-breaking authority. >> >> One solution to this problem is to have locks which time out, with an >> adjustable timeout value. Some locks could time out every day, every hour, >> or even after a week. This timeout value could be altered to meet the >> needs of the local environment. > >Perhaps it would be worth considering a DHCP-style lock - where you establish >a lock for a fixed period which can be renewed (without release) >periodically. > >Cheers, > >Ben. > >> >> - Jim >> >> > >-- >Ben Laurie Phone: +44 (181) 994 6435 >Freelance Consultant and Fax: +44 (181) 994 6472 >Technical Director Email: ben@algroup.co.uk >A.L. Digital Ltd, URL: http://www.algroup.co.uk >London, England. Apache Group member (http://www.apache.org) >
Received on Saturday, 28 September 1996 15:33:17 UTC