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.


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 -- -- tel:+492512807760

Received on Wednesday, 28 April 2004 17:24:31 UTC