- From: Geoffrey M. Clemm <gclemm@atria.com>
- Date: 1999年10月15日 09:12:04 -0400
- To: w3c-dist-auth@w3.org
- Message-Id: <9910151312.AA19799@tantalum>
You might wonder why 64x64 gives you 4048 interesting choices. I'd like to say that I evaluated all 4096 possibilities and found that 48 of them weren't interesting. I'm not saying that was what happened, but that's what I'd like to say (:-). Cheers, Geoff > From w3c-dist-auth-request@w3.org Fri Oct 15 08:16 EDT 1999 > Resent-Date: 1999年10月15日 08:13:04 -0400 (EDT) > Resent-Message-Id: <199910151213.IAA01870@www19.w3.org> > Date: 1999年10月15日 08:12:58 -0400 > From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com> > To: w3c-dist-auth@w3.org > Subject: Re: Static depth locking > Resent-From: w3c-dist-auth@w3.org > X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3469 > X-Loop: w3c-dist-auth@w3.org > Resent-Sender: w3c-dist-auth-request@w3.org > > > Ooops. Forgot one comment. I would modify Alan's proposal to say: > > Only LOCK and UNLOCK can add or remove a lock to a resource. > > In particular, DELETE does not add or remove locks on resources. > The reason is that a DELETE simply modifies the state of a collection > (by removing one of its bindings). There still can be other bindings > to that resource, and the lock should continue to apply. Only if > the last binding to a resource is deleted can the server garbage collect > that resource, which effectively deletes the lock. > > I believe that the simplicity of this rule far outweighs any benefits > achieved by special casing MOVE's and DELETE's (and dynamic depth locking), > both from a clients perspective (it can predict what operation will have > what effect) and from a servers perspective (it doesn't have to worry > about how to move/delete locks based on combinations of the user request > and the state of the arguments to that request). > > To give a flavor of the complexity of deciding this behavior otherwise, > consider the following variants of locking for a MOVE operation: > > pick 1 from the following 4 choices: > Source is unlocked. > Source inherits depth infinity lock. > Source is locked. > Source contains member(s) with locks. > > pick 1 from the following 2 choices: > Parent of Source is unlocked. > Parent of Source is depth 0 locked. > > pick 1 from the following 2 choices: > Lock is a regular lock. > Lock is a null lock. > > pick 1 from the following 2 choices > Lock is by requestor. > Lock is by other. > > pick 1 from the following 2 choices > Lock is through this mapping. > Lock is through different mapping. > > That gives us 64 interesting Source combinations. > > Now do the same for the Destination. > > That gives us 4048 interesting combinations of Source and Destination > locking states for a MOVE. This situation is not conducive to enumerating > the behavior for each interesting combination. > > Cheers, > Geoff > > From: "Babich, Alan" <ABabich@filenet.com> > Date: Thu, 5 Aug 1999 15:38:42 -0700 > > Why don't we do this: > > When you lock a collection: > depth 0: > shared lock placed on the collection resource: > no one can add or delete members > exclusive lock placed on the collection resource: > only you can add or delete members. > depth 1: > shared lock on coll.: no one can add or delete members. > First level members that exist at that time have > a shared lock placed on them. > exclusive lock on coll.: only you can add or delete members. > First level members that exist at that time have > an exclusive lock placed on them. > depth infinity: > shared lock on coll.: no one can add or delete members. > Members at any level(including subcollections) > that exist at that time have > a shared lock placed on them. > exclusive lock on coll.: only you can add or delete members. > Members at any level (including subcollections) > that exist at that time have > a shared lock placed on them. > When a resource is moved out of or into a collection, the lock(s) > of the resource don't change (assume the move is allowed). > No locks are ever created or deleted as a result of an ordinary > resource or collection resource being moved (assume the move is > allowed). > > When you unlock a collection, depth n, you do the inverse > of the operation described above on the members that exist > at the time the unlock of the collection is executed. > > Remember that a resource can be in multiple collections at > the same time. In fact, in some systems, that is the normal > case. If a resource X is in two collections C1 and C2, > locking C1 does not prevent the resource X from being removed > from collection C2. Nor does it prevent the resource X from > being inserted into collection C3. There are no locks > placed or removed as side effects of MOVE. Only LOCK, > UNLOCK, and DELETE mess with locks. > > Alan Babich > > > > > > >
Received on Friday, 15 October 1999 09:12:07 UTC