- From: <ccjason@us.ibm.com>
- Date: Wed, 18 Aug 1999 14:44:55 -0400
- To: jamsden@us.ibm.com
- cc: w3c-dist-auth@w3.org
<JC> 3) 8.10.5 says a DELETE destroys a lock at the destination. I think this is not optimal. A scenario is... /a/b exists and is a resource... not a collection. We want to replace it with a new resource that is a collection. But the spec says that MKCOL can not replace am existing resource (or collection). It requires that a delete be performed first. Now if one wants to accomplish this atomically (with LOCKS), right now one has several choices. a) LOCK /a/. It would probably be a depth 0 lock since there would be no point in locking at depth except possibly to prevent someone from tossing in another lock immediately after in the /a/b/... tree. But if they did chose to use a depth lock, they'd also risk being unable to get the lock if someone for example has a conflicting lock somehwere in a /a/c/ tree. It's a trade off. Depth or not, the other disadvantage of it is that they are also locking out any operations on /a/. The point is that if they decide to lock /a/, they are locking more than they need to and may interfere with other principles... or be blocked themselves. b) LOCK /a/b. But unfortunately with the current spec, the initial DELETE will destroy the lock. So this isn't really a choice unless we want to reissue the lock... to create a null lock which is better, but still risks problems if another entity beats us to the punch. It's a race condition. Now if we altered 8.10.5 to allow support for not deleting the lock, we could act surgically to insure that we get exactly the safe atomic behavior we want. (Ignoring a tangential caveat.) We lock /a/b possibly at depth. Do the delete specifying that we want the lock retained. Then do the MKCOL /a/b/ and any other operations we require. When done, release the lock. Once again ignoring an unspecified caveat, we know that as soon as we get the lock that we're going to be able to acomplish what we set out to do without another principle interfering. If we don't want this, then I think we need to evaluate why we support lock-null resources. I'd think the arguments for each of these are the same. </JC> <jra> There are a large number of situations in authoring environments where transaction semantics are required. WebDAV doesn't (yet) support transactions, and I don't think we should attempt to come up with a lot of special cases (like lock-null resources) supported by the protocol to overcome this important missing function. Rather let's propose an extension that does support transactions. Might be pretty hard with a stateless server though. </jra> <JC> So you're not a fan of lock-null resources either at this stage. That seems consistent. JimA and I have been doing all the talking for the last day. Anyone else want to be heard? :-) </JC>
Received on Wednesday, 18 August 1999 14:46:20 UTC