- From: Lisa Dusseault <lisa@xythos.com>
- Date: Wed, 28 Apr 2004 14:24:00 -0700
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Elias Sinderson <elias@cse.ucsc.edu>, Webdav WG <w3c-dist-auth@w3c.org>
So far we've only considered lock "stealing" for the purpose of destroying a lock (e.g. if somebody locked a file and went on vacation). If I steal somebody else's lock to use it and change the file while still leaving it under the same lock there *will* be interoperability problems because there's no way to coordinate. Going from that limited UNLOCK use case to a more general content management use case, where multiple people might use the locked resource is a big step and we don't have a lot of experience (that I know of). Recall that shared locks were invented for the latter case, not exclusive lock token sharing. Lisa On Apr 28, 2004, at 2:05 PM, Julian Reschke wrote: > > Elias Sinderson wrote: >> ... >> I agree with the above proposed text, however it may lead to some >> interoperability issues. Is there a proposed mechanism to allow >> clients to discover how a server handles the intersection of these >> design choices? > > I'm not sure we need that kind of discovery. Keep in mind that we're > talking of an exceptional edge case where somebody "steals" a lock > that was created by somebody else. We don't need to make that simple. > Trying and seeing the outcome should be ok. > > Or am I missing a more regular use case? > > Regards, Julian > > -- > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 >
Received on Wednesday, 28 April 2004 17:24:31 UTC