- From: <ccjason@us.ibm.com>
- Date: Fri, 15 Oct 1999 16:34:33 -0400
- To: jamsden@us.ibm.com
- cc: w3c-dist-auth@w3.org
>> A principal can only have one lock on a resource. If the lock is exclusive, then there can only be one. If the lock is shared, then getting another shared lock would not give owning principal any further capability. I don't have the spec if front of me, but I believe this is spelled out. >> I believe the spec implies what you say. Feel free to double check that. It would be useful to know where it says/implies that... but I'm also suggesting a change if that's what the spec says... not just asking what the spec says. It does give new capability though. It's the right hand/left hand thing. Two independent client tools using the same ID. They both want to block writes to (coincidentally) the same resource. Sure the second locker could do a lock discovery... but then they'd also have to work out who is the last one that wants to release the the lock. Remember... these are independent tools. It won't work without some cooperation. And having multiple locks on the same resource solves this problem neatly. As my note says, it looks like the spec already supports this for inherited shared lock to some degree. If so, the issue then becomes... "Can the two shared locks owned by the same entity be rooted at the same resource?" I'm suggesting they should. J.
Received on Friday, 15 October 1999 16:30:32 UTC