- From: WJCarpenter <bill@carpenter.ORG>
- Date: Tue, 25 Jan 2000 14:58:57 -0800
- To: w3c-dist-auth@w3.org
gmc> The second issue is whether a client other than the lock gmc> requesting client should be able to use the lock token to get gmc> access to a resource. Doing so would violate the whole design of gmc> the lock token scheme, which is to have a protocol for reliably gmc> deciding whether a *particular* client has the authority granted gmc> by the lock token. The protocol only works if only the client gmc> that made the LOCK request uses the generated lock token. The gmc> fact that the lock token was issued to a particular principal is gmc> irrelevant. This doesn't address other reasons for doing unambiguous lock discovery. It leaves aside such rainy day scenarios as "oops, my application just crashed (et seq :-))" and "I guess I'll go home for the night and work on this". gmc> So a client should always get its own lock token, not appropriate gmc> an existing one. If a resource is already exclusively locked, it gmc> first will need to UNLOCK the resource. This then guarantees gmc> that if the other client (that issued the LOCK request) is still gmc> around, it will notice the "cancellation" by the failure of its gmc> next update request. This technique also opens a (probably very small) window wherein someone else could grab the lock. (Such events are not always a matter of competition. You could be under the impression that your co-author was going to release the LOCK when s/he was done and it was your turn.) -- bill@carpenter.ORG (WJCarpenter) PGP bill@bubblegum.net 0x91865119 38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3
Received on Tuesday, 25 January 2000 18:03:56 UTC