- From: <ccjason@us.ibm.com>
- Date: Tue, 3 Aug 1999 15:18:44 -0400
- To: "Slein, Judith A" <JSlein@crt.xerox.com>
- cc: w3c-dist-auth@w3.org
> I think it was our intention that the advanced collection spec be consistent > with the lock semantics described in rfc 2518. In fact, we explicitly say > this is the case in 4.2.11 LOCK and UNLOCK. I'd like to point out that there are a bunch of issues with the current lock design of rfc2518. JimW says that he's put them on the issues list. I don't think we can lean on the rfc2518 lock design until those issues get worked out. >> My own feeling is that when you MOVE a resource, the result is the same resource, with all the same properties, at a different location. So it should have the same lock that it had at the source location. >> I'm with you, but I want to hold off on commenting further until we've collected all the LOCK issues in one place. JimW seems to be collecting them. (Thank you Jim.) >> On the other hand, when we are thinking about simple resources inheriting locks from their parent collections, and moving a bunch of these resources around, it is certainly simpler to manage the locks if the simple resources inherit locks dynamically from their parent collections -- so that when you unlock a collection, you unlock all the resources that are in it at the time of the unlock rather than the ones that were in it when the lock was applied (which may reside anywhere by the time the lock is removed). >> Yes, good observations. This should be added to the issues list to make sure it isn't overlooked when we discuss locking. The issue of depth locking needs to be clarified. >> The earlier rationale for having MOVE destroy the lock on a resource is at http://lists.w3.org/Archives/Public/w3c-dist-auth/1997JulSep/0177.html. >> This link should be added to the issues list. Jim....? :-) J.
Received on Tuesday, 3 August 1999 15:18:42 UTC