RE: v6: 12.9 lockdiscovery

At 07:50 AM 2/4/98 PST, Dylan Barrell wrote:

>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.

Dylan.

You raise a good point about the potential for user confusion, but I don't
think it's strong enough to justify removing lock tokens.

Lock tokens solve the following problem (Yaron has already said this, but
perhaps I will say it differently?)

In the modern era of computing, a user typically does not (and can not)
know the full set of programs that might be acting on his/her behalf (with
the full access rights of that user), nor can he/she know what resources a
given program will be using.  So you can have a situation where two
programs are running, and they both need exclusive access to a resource.
Neither one knows about the other, and the user does not know about at
least one, if not both, and hence can't be umpire.  If locking is based
only on identity of the principal, then program B can smash the data of
program A.

Lock tokens allow one program to exclude all others, even those with the
same authentication rights.
 
By default, program B will just fail to get the lock, in the same way as if
the resource were locked by some other user.  If B is smart, it can do lock
discovery, realize that the lock is help by another program also acting on
behalf of the same user, and try to decide what to do.  It might just go
ahead and blindly do the operations it wants, (living dangerously), or it
might pop up a dialog box and ask for advice.  

I can very easily believe you when you say that users won't know what such
a dialog box really means.  This might be an argument that the author of B
should not even try but should just have the program die gracefully.  but
it is not an argument against lock tokens, because if you did not have
them, B would have not even know about the problem, and would have
clobbered A, and if you think the dialog box was confusing, think how much
worse this would be.

I hope I have explained the rationale for lock tokens.

In any case, I must say that lock tokens are only a small portion of the
WebDav spec, and are, I think, expressed fairly clearly.   If you take
complexity of the specification as an argument against a feature, then you
will surely have even more objections when DASL (search), access control
lists, or ordered collections come down the line.

Best regards

Jim

Received on Wednesday, 4 February 1998 17:52:55 UTC