- From: Yaron Goland <yarong@microsoft.com>
- Date: Wed, 4 Feb 1998 00:31:03 -0800
- 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 UTC