- From: Jim Whitehead <ejw@ics.uci.edu>
- Date: Tue, 25 Jan 2000 15:34:20 -0800
- To: WJCarpenter <bill@carpenter.org>, w3c-dist-auth@w3.org
Bill Carpenter writes: > 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". When dealing with exclusive locks, the lack of owner information is more an inconvenience than a problem in the situations you mention. A client can retrieve the lock token by performing lock discovery, and then assume it belongs to that client. The server will let the client know if this isn't the case. To prevent a user from doing too much work before they discover the lock token doesn't belong to them, the application should pop up a dialog letting the user know what happened, and then try to write a dummy property using PROPPATCH (or some other simple, easy-to-undo write operation), and see if the method succeeds. > 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.) So, I'm not as opposed to grabbing an existing lock token as Geoff is. If a client does seize a lock token, the application should inform the user of this. - Jim
Received on Tuesday, 25 January 2000 18:38:28 UTC