- From: <ccjason@us.ibm.com>
- Date: Fri, 7 Jan 2000 17:34:35 -0500
- To: "Eric Sedlar" <esedlar@us.oracle.com>
- cc: w3c-dist-auth@w3.org
> * a LOCK token must be associated with the locked resource and URL > Umm? This doesn't sound like a requirement. At least not a fundamental > one. Feel free to explain what you mean if you think this is an important > point. > I had this as a requirement for compatability with RFC 2518. Are you suggesting that lock tokens are superfluous and should be removed? No. Just that lock tokens are an implementation of a requirement, not a requirement in and of themselves. If the same can be achieved in some other way, that's fine. You seem to be shooting for compatibility in which case LT are the mechanism to use. -- I didn't actually understand the point of your statement either. That's fine though. What's most important is what you say below. It wasn't clear to me in general if shared locks were the default rather than exclusive, but it seems natural that this should be the case for both name and resource locks. I hadn't considered the possibility of name locks being exclusive. The need for this wasn't one of our requirements. We just wanted to protect a URI from having it's mapping change. This was purely for the sanity of the client. My initial vote for resource locks is that there be no default. One must specify what one wants. As far as treating name locks as a formal entity, that is a better way of describing what you are doing when you want a lock on a URL not associated with a resource--you're locking only that PART of the collection resource corresponding to that name in its set of bindings, you aren't locking some resource that that name will be associated with later. I'll just try harder to assimilate this view. I think that people who have worked with locking before understand the difference between locking an aggregate object and an individual item in that aggregate, as there are many examples of that in software today (locking a file vs. locking a byte range in that file, table locks vs. row locks in a SQL database, etc.). I don't think people are comfortable with the idea of treating namespaces as lockable entities separate from the entities the names refer to, since that isn't generally done. Actually, only Geoff's most recent proposal couched it that way. All others have tended to say that a predetermined set of bindings are "protected". The term "locked" wasn't used... and after it was set up, it wasn't based on namespace... just bindings. Once you agree that the set of bindings are part of the state of a collection, you are treating the collection resource as an aggregate that can be locked, as well as one or more bindings it contains. The model I propose is simpler, in that only one kind of object WebDAV requests can refer to--the resource, without treating URLs as something separate. A good thing. URL's are just a side effect. I forget the word Geoff used to use to refer to this. > I agree with the semantics, but I'm uncomfortable with creating a new > concept > called a "lock set". This also rings of "implementation". > Hopefully this can be avoided. Anyway... The lock set is just a group of locks associated with a single lock token. Given that the Depth: infinity header effectively gets many locks (rather than one big lock) and associates them with a single token, you were already doing this before, just without a name. It just seemed to me to be easier to understand if you have a term for describing what a lock token identifies. This is just a terminology issue. I am still uncomfortable speaking of sets of locks. Also, that's not what we had before except in one proposal that someone made (twice) but that proposal didn't last long. People liked the dynamic nature of this. That's not to say that it had to be based on namespace. Just parentage. Perhaps I shoudln't say this, but with the advent locking of collections, do we still need depth locks? I forget why this was important and what set of people felt it was important. I know Jim Whitehead was one of the people and I believed the others were document management folks that wanted to to lock composite entities. Anyway, I just wanted to check if we still need them. If so, I'd like to explicitly note this in the locking doc I'm doing. Re: Depth locking... > An RFC 2518 LOCK > request applied to a collection will work in the same way, except that > if > the depth header is specified, name and resource locks will be given > recursively for each contained resource. > > Hmmm. Or perhaps just resource locks. No, that won't work either. > Okay... > You're going to have to explain some of the > complications of this. Like, are all of these resources still locked if > you > remove the binding that put them under the influence of the original lock > request? No. The LOCK protocol request is a shorthand way of requesting a set of names and resources to lock. Deleting one of the names or resources you have locked removes the locks, since you have nothing there remaining to lock. The DELETE only removes the binding. The resource may still exist and be exposed at other URI's. More below. The validity of the relationships between the set of names that are locked and the resources they apply to is not maintained. Here's a boundary case to illustrate the issue: Let's say I have resource ID 1 bound by foo.html, ID 2 bound by bar.html, and ID 3 bound by werf.html, all in the same collection. Now, I issue 3 LOCK requests on each URL, and get lock tokens T1, T2, & T3. Now (using a temporary URL) I MOVE everything around so that foo.html refers to resource ID 2, bar.html refers to ID 3, and werf.html refers to ID 1. LOCK token T1 still refers to foo.html and resource ID 1, even though foo.html now refers to resource ID 2, and if I UNLOCK with token T1, foo.html and resource ID 1 are unlocked. Yucky! A very nice clean model, but it doesn't serve the client very well if the methods will act this way. Letting a LT's name locks get separated from it's resource locks seems like a bad idea and probably serves no purpose. In addition, the client can't release one type of locks (name) without releasing the other (resource)... unless the client creates two lock sets explicitly. > I have to provide token T2 to UNLOCK resource ID 1. I think you mean you have to use T1 to unlock ID 1, but you have to use T2 to unlock the name/binding/slot that currently maps to ID 1. > And does adding a resource to a depth locked collection, create a > resource and name lock for the newly bound resource? I would say that the default for this would be no, since again the relationships between the names and resources is not something that the server enforces--only clients can do that via use of locks. Since the collection is locked, you would have to provide the lock token to insert the new resource into the locked collection anyway. The thinking on the list has been that they want it automatically extended to the children. Folks have questioned this on occasion and the folks that value depth locks have always expressed a preference for the locks automatically being extended to children. In addition, they liked having the lock stop applying to any child resource that leaves the locked tree. However, there may be some need for combining the PUT and LOCK into the same request to avoid race conditions. I can see this being an issue with a number of protocol requests (BIND & LOCK, etc.). There probably needs to be a way to add a lock as a part of any WebDAV request. Perhaps folks would find this acceptable. That is, if a client is adding to a locked collection, the client can specify that the lock be extended to what it is adding to that collection. -- Or perhaps we'd make the default to extend any depth locks affecting the collection into which a resource is added. Noone has mentioned actually wanting it NOT to be added. > And do name locks remain > if a subtree is separated from the tree where the original LOCK request > was submitted. Yes. That is why each name in the path (logically) is locked separately, to simplify the task of tracking all of these types of issues. When stated as I did above, people have expressed a preference to having the inherited locks stop acting on the resources that move/delete away. But if it was the resource itself that was originally locked (not via inheritance) many folks like it to continue to affect the resource even after movement/unbinding. > If you delete a locked binding, is the name lock automatically deleted? If you DELETE a locked resource, the resource lock is removed from the lock set, leaving only the name locks. I.e. I Lock /a/foo.html. Then I delete /a/foo.html. I still have the name lock, so nobody else can put something at /a/foo.html (I'm reserving the namespace like an LNR). I think this will be needed for doing certain types of tree manipulations as an atomic unit. Reserving the namespace can be a good thing. As for unlocking the resource that was deleted... remember, DELETE just removes a binding, and does not necessarily destroy the resource. It may or may not having other bindings and mappings. I don't disagree that this might be the right thing to do, but if we do decide to unlock that resource, we have have to cross our fingers when we say the resource lock is on a resource. > Thus we get the benefit of LNR's without having to create a pseudo > resource > there. Presumably PROPFIND will not pretend there is a resource there > either. > This sounds very good. It's the main positive point I see in this > proposal. Right. This is the main goal of my proposal, to create an abstraction that is general. > 3) the activelocks property displays all name locks active for this > collection as well as all resource locks. > > BTW, Would activelocks on a collection would reveal name locks on > descendents > rather than the name locks of bindings to the collection? Hopefully. Yes. The activelocks property (as a property of the collection) should only reveal state belonging to that collection. Since the list of bindings to descendants is the state of the collection, activelocks would list any locks on those names. Yea! So "LNR"s will reject PROPFIND requests just like ordinary null resources. Good stuff. > 4) the "locktype" property is used to distinguish between name and > resource > locks. If locktype "resource" is specified, only the specified > resource > lock is granted in that lock set. If locktype "name" is specified, the > names from root to the resource are locked, if the Depth header is not > specified. > > > If the URL "/a/b/c.html" is given, negative depth values can be > given to lock fractions of the path. E.g. if Depth:0 is specified, the > name > "c.html" is reserved in collection /a/b, but no other locks are > granted. > If > Depth:-1 is specified, the name "b" in "/a" is also reserved (etc.) > Only if > locktype is not specified does the LOCK request behave as it point #2 > (granting resource & name locks simoultaneously), basically for > compatability with existing applications. > > Is all this needed? I thought the point in locking the name was to insure > that > the locked resource remained accessable to the client at a known URI? > "-1" > doesn't achieve that and may prevent trivial implementations on top of > some > respositories. I'm also not sure I understand the motivation (at least > given our > current capabilities) of a client locking a resource without also locking > the > namespace. Currently it doesn't seem helpful to lock a resource if you > can't > get at it subsequently. I can see the value of allowing a URL reference that is derived from a resource ID, like "/resources/1234" or something in some implementations (Oracle's implementation will have this). Resource ID is constant regardless of BINDings. I recommend adding something like this to the protocol. I can see the value in that too. It sounds like something that could neatly go in a separate proposal. It doesn't impact anything else. Still though... I have my doubts that all of the above concerning negative depths is worthwhile. And in fact for platforms like IIS that want to use native capabilities, I don't think they'll be albe to do anything other than lock all of the bindingss up to the root.
Received on Friday, 7 January 2000 17:35:08 UTC