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

Re: Lock timeouts revisited

From: Ben Laurie <ben@gonzo.ben.algroup.co.uk>
Date: Sat, 28 Sep 1996 11:18:38 +0100 (BST)
To: Jim Whitehead <ejw@ics.uci.edu>
Cc: w3c-dist-auth@w3.org
Message-ID: <9609281118.aa20290@gonzo.ben.algroup.co.uk>
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.



> - 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 07:14:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:08 UTC