- From: Lisa Dusseault <lisa@osafoundation.org>
- Date: Wed, 14 Dec 2005 13:24:48 -0800
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: w3c-dist-auth@w3.org
One could imagine the lock applying to the resource and to all its bindings, considering the bindings to be part of the state of the resource. If I recall, I think this is the model I'd always assumed until GULP. With this model, if A and B are bindings to a resource, and a LOCK token to A is successful, then for the duration of the lock the token is required to change either A or B. In today's server implementations, does a LOCK of depth 0 on a collection prevent MOVE from being used to change resource names inside the collection? This is another possible case that might be different depending on whether bindings were considered part of the collection, part of the resource state, or both. Lisa On Dec 14, 2005, at 1:15 PM, Julian Reschke wrote: > Lisa Dusseault wrote: >> Good question, and I'm not sure -- it depends what the consequences >> are of assuming this distinction. It seemed like a useful >> distinction until it led to what, to me, were unexpected or undesired >> consequences. > > Well. If not using this term, how do you distinguish between the > resources that are actually locked, and the URLs that are protected? > So for instance, with a > > /a/b > > being lcoked (through a LOCK request on /a/b), how do you describe the > fact that the URL is protected by the lock (that is, you'll need a > lock-token to MOVE /a itself)? > >> Do any servers implement multiple URLs, locking and DELETE >> (regardless of whether they support the exact model of BIND)? If >> so, what do existing implementations do? > > Yes, we do, and of course we implement the model we discuss. > > Best regards, Julian
Received on Wednesday, 14 December 2005 21:25:07 UTC