RE: v6: 12.9 lockdiscovery

81 pages of standard to be exact. Although the next version will be shorter.
=)
	Yaron

> -----Original Message-----
> From:	Dylan Barrell [SMTP:dbarrell@opentext.ch]
> Sent:	Wednesday, February 04, 1998 7:50 AM
> To:	Yaron Goland; 'Jim Davis'; 'w3c-dist-auth@w3.org'
> Subject:	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:48:29 UTC