Infinite depth locks and unlocking

Since locking is a bit of a rage at the moment, I just wanted to clarify
something relating to infinite depth locks.

I believe according to the spec that if I do a depth infinity lock
on /a/b/c then if I do an unlock on /a/b/c/d/e using the same lock
token, the lock is completely removed from all resources (that is,
from /a/b/c down).

Other possible interpretations that I think are not what the spec says are

(1) /a/b/c stays locked, only /a/b/c/d/e (and descdenants) are unlocked

(2) You are not permitted to unlock /a/b/c/d/e - you should unlock /a/b/c

I also noticed that if you successfully delete a resource (a binding?)
then 'all its locks are removed' which for a depth infinity lock
implies that if you delete /a/b/c/d/e then the lock on /a/b/c would
also be unlocked.

With the recent lock and lock null resource discussion, I was trying
to rethink what is the best way to implement locking with depth infinity.
I had previously come to the opinion that the easiest approach to get
the semantics right was to keep a lock table of URLs - not apply
the locks to the real resources. This is because you do not unlock
single resources, you remove the depth infinity lock from the table.
(There might have been other reasons as well.)

But the current semantics of depth infinity lock is not the same as
depth 0 locking all of the resources in the tree. This creates weird
edge cases (such as above) which I am not 100% of sure the correct/best
way to resolve.

Does anyone use depth infinity locks? How have people implemented them
such that deleting /a/b/c/d/e will remove the lock on the whole tree?
Or am I missing something here?

Thanks!
Alan

Received on Friday, 24 August 2001 00:40:58 UTC