W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2004


From: Lisa Dusseault <lisa@xythos.com>
Date: Wed, 28 Apr 2004 14:24:00 -0700
Message-Id: <5DDCFA2A-995A-11D8-B566-000A95B2BB72@xythos.com>
Cc: Elias Sinderson <elias@cse.ucsc.edu>, Webdav WG <w3c-dist-auth@w3c.org>
To: Julian Reschke <julian.reschke@gmx.de>

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 -- http://www.greenbytes.de -- tel:+492512807760
Received on Wednesday, 28 April 2004 17:24:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:31 UTC