- From: Kevin Wiggen <wiggs@wiggenout.com>
- Date: Thu, 19 Aug 1999 11:42:42 -0700
- To: <ccjason@us.ibm.com>, <w3c-dist-auth@w3.org>
It is my understanding that locking a collection simply locks the namespace of the collection. If /a is locked by L1 and /a/b is locked by L2 Then to change /a/b I only need to give L2, since /a's namespace will not change. Thus if /a/b is a null-resource, and you have the lock, then you can change it at will through a PUT. MOVE/COPY are interesting in the fact that if the whole operation is not automic, then the Delete will fail due to the changing namespace.. I would assume that the MOVE/COPY would work without L1 if I were a client program. Is this not how it is supposed to work?? Kevin -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of ccjason@us.ibm.com Sent: Thursday, August 19, 1999 11:14 AM To: w3c-dist-auth@w3.org Subject: LOCK NULL reserves what? Whoops, I sent this to the wrong address last night.... My comments in my previous note remind me of something else. If I have a lock-null resource, and if someone places a lock on the parent collection, am I blocked from doing a BIND or MOVE on my lock-null URI? I believe the intent of the lock-null is to insure that we can do operations like PUT/MKCOL there... but I'd think that BIND and MOVE also apply... at least in intent... but that seems to conflict with what we've been saying about BIND/MOVE being an operation on the state of the parent collection... and thereby blocked if someone else locks the parent. Any thoughts? Yaron? :-) ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com
Received on Thursday, 19 August 1999 14:48:39 UTC