W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 1998

RE: v6: 12.9 lockdiscovery

From: Yaron Goland <yarong@microsoft.com>
Date: Wed, 4 Feb 1998 00:31:03 -0800
Message-ID: <3FF8121C9B6DD111812100805F31FC0D0113C801@red-msg-59.dns.microsoft.com>
To: "'Dylan Barrell'" <dbarrell@opentext.ch>, "'Jim Davis'" <jdavis@parc.xerox.com>, w3c-dist-auth@w3.org
More often than not users don't even know that a program they are running
has locked a file or that it will want to lock a file. 

For example, which word processors lock files they are working on? Think
carefully because not all of them do it. 

Furthermore when a user is interacting with the system through other
mechanisms, such as backing up the system or copying a directory, it is
quite likely that they may end up effected a locked file without knowing it
before hand. 

Given that programs often lock files or effect locked files without the
user's knowledge it is therefore self evident that a user may have no idea
of the ramifications of their actions until a program politely points it
out. Hence the lock token requirement.

		Yaron

> -----Original Message-----
> From:	Dylan Barrell [SMTP:dbarrell@opentext.ch]
> Sent:	Tuesday, February 03, 1998 4:37 PM
> To:	Yaron Goland; 'Jim Davis'; w3c-dist-auth@w3.org
> Subject:	RE: v6: 12.9 lockdiscovery
> 
> Dylan, we provide a very specific example for why we believe that lock
> tokens are absolutely required.
> 
> [Dylan Barrell]  As I said, the example is weak at best. If a user takes
> out a lock THEY KNOW THEY HAVE TAKEN IT OUT. If they then perform PUT with
> another application to that locked resource THEY KNOW WHY. The advantages
> of requiring  lock token just so that the application can then warn them
> that a lock exists on the resource (when it could do this without
> requiring the lock token) IS NOT WORTH THE EFFORT. My belief is that a
> standard should have the minimum requirements to allow disparate systems
> to interoperate effectively. Lock tokens are not required in order to
> fulfill this requirement.
Received on Wednesday, 4 February 1998 03:31:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:44 GMT