Re: If: header and "parent" resource checking

   From: jamsden@us.ibm.com

   I believe a "lock-null" resource is best treated as a convenient
   fiction maintained in order to make it easy to query for the existence
   of locks.

   In particular, according to section 7.4 of 2518, a lock null resource
   acts the same as a null resource for all methods except for PROPFIND
   and UNLOCK. A DELETE on a lock null resource MUST fail, a MOVE on a
   lock null resource MUST fail, a COPY on a lock null resource MUST
   fail, etc.

   The reason I am particularly concerned that the creation of a lock NOT
   be treated as a modification of the state of the parent collection is
   to ensure that effect of creating a lock-null resource is treated
   consistently in the versioning and the locking protocols.

   <jra> The lock-null resource appears as a member of its parent
   collection, so it must modify its state. Otherwise, how would one
   see the results of the LOCK request?
   </jra>

By stating in the protocol that "although a lock null resource shows
up in a PROPFIND, adding or removing a lock null resource in a
collection has no effect on the lock state of that collection".

There is clear precedent for this in the treatment of live properties,
which also can be modified without affecting the lock state of the
resource containing those properties.

   In the versioning protocol, the creation of a lock-null resource
   cannot be a modification to the state of the collection containing
   it, because if the collection were versioned, this would then
   require a new revision of that collection in order to hold the "new
   resource". But then this lock-null resource could never be removed
   from this collection revision, because revisions are immutable.

   <jra> The versioned collection only needs to have a working
   revision. The lock-null resource may be deleted (with unlock) or
   converted to a real resource (with put) before the working revision
   of the versioned collection is checked back in.
   </jra>

When a lock is performed by a versioning unaware client in a versioned
collection, the creation of the new collection revision is done
automatically as soon as the state of the collection is modified.
There is no working revision involved, other than the one that is
automatically checked in to create the new revision.  And that new
revision will contain an immutable "lock-null resource", which would
effectively prevent the ability to ever UNLOCK that lock.  Not a
good thing.

   On the other hand, if the addition of a lock is not considered a
   modification to the state of a collection, but rather the
   modification occurs at the first PUT, then all is well ... no
   "immutable" locks end up being captured.  In this model, a lock is
   not a modification to the state of a resource (either the resource
   itself, or the collection containing the lock), but rather
   "metadata" that controls interactions with the state of the
   resource.

   In versioning, this is also how "labels" are handled, i.e. as
   metadata on a resource that does not modify the state of the
   resource.

   I'd *very* much like the versioning protocol and the locking
   protocol to be consistent as to whether the creation of a lock-null
   resource modifies the state of the collection containing
   them. Since I don't see that the versioning protocol has a choice
   in this regard, I'd like to see the locking protocol handle it the
   same way, unless there is some serious problem that arises from
   doing so.

   So I guess what I'd like to hear is why it is important for the
   addition of a lock-null resource to be treated as a modification to
   the state of the collection containing it.

  <jra> Just so you can see the results of the LOCK operation and have
   a URL to unlock or put.  </jra>

As indicated above, any live properties can be defined as being changeable
without affecting the lock state of a resource.  Stating that a lock
null resource can be added or removed from a collection without affecting
the lock state of that collection can be handled in exactly the same
way, while keeping the ability to use PROPFIND to locate lock-null resources.

Cheers,
Geoff

Received on Monday, 29 May 2000 22:36:40 UTC