- From: Dan Brotsky <dbrotsky@Adobe.COM>
- Date: Wed, 27 Jun 2001 16:55:40 -0700
- To: "Jason Crawford" <ccjason@us.ibm.com>
- Cc: <w3c-dist-auth@w3.org>
At 6:13 PM -0400 6/27/01, Jason Crawford wrote: ><< >1. lock-null resources are just "regular resources" that are required >to respond to certain methods in certain ways. >>> >I'd like to suggest that LNR's are *not* regular resources. With one >exception that I've noticed, they are just "null resources" that have >a lock affecting them. Jason, I wasn't suggesting that LNRs, as *currently specified*, are regular resources. I was trying to summarize the back-and-forth between Tim and Jim as concluding that they *should* be regular resources, that is, that LOCK of an unmapped-URI should create a (mostly) standard, no-content resource mapped to that URI. Sorry if this wasn't clear from my message. The reason for the (mostly) qualifier above, by the way, is that the no-content resource created by a LOCK call in this proposal would not start off as a collection but could become a collection if a MKCOL was then done. (That's why I was also suggesting we needed a new value for the DAV:resourcetype property.) Geoff is suggesting something slightly different: that LOCK not even be allowed on unmapped-URIs. This also gets rid of LNRs and has the advantage that you always know whether something is a collection or not. However it doesn't allow users to simultaneously create and LOCK resources for further editing, which bothers me. >Think about a resource /b/ that has a depth lock and /b/a that is a >null resource. Think about how /b/a behaves. It's not a LNR resource, >it's just a totally normal "null resource" (or unmapped URL), but it >seems to have the same behavior as a LNR. The exact same behavior. > >Except for one thing... > >The exception is that we've defined PROPFIND to not give a response >for /b/a yes we have. It gives a 404 (Not Found). >but we have specified that PROPFIND give a response to a >LNR. well, a different response (207). > >That's the only exception, right? (This is a genuine question.) And the answer is no. If you do a PUT on /b/a (in the unmapped case) it will succeed, but if you do a PUT on /b/a (in the LNR case) it will fail with a 423 Locked [or 412 Lock Token not specified as Precondition]. It's important not to forget that the big difference between an LNR and an NR is the L! :^) >This being the case, I'd like to get away from talking about a LNR as a >normal resource or an particularly odd type of "null resource". Instead >we can say that we are allowed to lock a null resource that has a parent >and that PROPFIND has special behavior for a null resource that has a lock >rooted on it. If we can talk about something being "odd", we can talk >about PROPFIND being odd. I think the language about null resources makes these situations seem similar when they're not. That's one of the reasons I like Tim's "unmapped-URI" language much more. IMHO, there is no such thing as a "null resource;" there are only resources (some of which have content and some of which don't). If you want locks to be on resources, which the spec does, then you either have to have LOCK create a resource (my thinking) or you have to forbid LOCKs on URIs that aren't bound to a resource (Geoff's thinking). Of course the other thought in the air is to make locks be on URIs and not resources at all. But even in this case I think you want to disallow locks on unmapped-URIs, because such locks (given the semantics of PROPFIND, which is about resources not URIs) would not be discoverable nor would they be presentable as "resource state". These two outcomes would require a major revamp of the spec. My guess about where we're going to end up is that LOCKs are requested on and attach to the *binding* between a URI and a resource, and that they control that resource regardless of which URI it is accessed through. That would disallow LOCKs on unmapped-URIs, and it would also account for why LOCKs on a particular URI/resource binding are destroyed when that binding is destroyed (such as by a MOVE request). It would also make it easy to say how LOCK and BIND are related (in the deltaV spec). dan -- Daniel Brotsky, Adobe Systems tel 408-536-4150, pager 877-704-4062 2-way pager email: <mailto:page-dbrotsky@adobe.com>
Received on Wednesday, 27 June 2001 19:55:55 UTC