RE: v6: 12.9 lockdiscovery

This argument also argues against having them because the user won't know whether it is safe to overwrite the file when confronted with the dialogue box for confirmation so the protection that they provide is very weak and therefore not worth the effort of both the client and server implementations having to manage the lock tokens they are dealing with, the implementors of these systems having to become acquainted with yet another standard etc.

Cheers
Dylan

-----Original Message-----
From:	Yaron Goland [SMTP:yarong@microsoft.com]
Sent:	Wednesday, February 04, 1998 9:31 AM
To:	'Dylan Barrell'; 'Jim Davis'; w3c-dist-auth@w3.org
Subject:	RE: v6: 12.9 lockdiscovery

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 16:44:24 UTC