(unknown charset) Re: If: header and "parent" resource checking

On Mon, 29 May 2000 jamsden@us.ibm.com wrote:

[ rest of quoted post by Geoff Clemm, but Jim's mailer appears incapable
  of useful quoting :-) ]

> See <jra> tags below.
> 
> 
> 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>

Agreed. No matter what people think of locknull resources, they do exist,
and they do modify the parent collection. My previous post went over this,
and I see nothing "funny" about different behaviors when different states
exist on the server.

> 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>

Dunno what would be The Right Thing, but maybe a CHECKIN or MERGE (or
whatever it is called nowadays) could fail if a locknull existed.

Personally, I'd just refuse to create locknull resources in a versioned
space. Maybe even disable locking altogether.

>...
> 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>

Yup. Locknull resources exist to "reserve" a particular member in a parent
collection. You have to modify the parent to assert that the member has
been reserved.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Received on Monday, 29 May 2000 20:39:24 UTC