Subject: Re: If: header and "parent" resource checking

From: [email-masked]
Date: Mon, 29 May 2000 09:10:42 -0400

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>

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>

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>

---

From: Greg Stein <[email-masked]>
Date: Mon, 29 May 2000 17:39:16 -0700 (PDT)

On Mon, 29 May 2000 [email-masked] wrote:

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

> must modify its state. Otherwise, how would one see the results of the LOCK

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.

> resource (with put) before the working revision of the versioned collection

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.

>...

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/

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Mon, 29 May 2000 22:36:23 -0400 (EDT)

From: [email-masked]

   <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

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Mon, 29 May 2000 23:15:41 -0400 (EDT)

From: Greg Stein <[email-masked]>

   No matter what people think of locknull resources, they do exist,
   and they do modify the parent collection.

The fact that they show up in a PROPFIND does not require that their
addition and removal from a collection affect the lock state of that
collection.  I'll appeal again to live properties here.  They are
properties of a resource, but they can be changed without affecting
the lock state of the resource.

   My previous post went over this, and I see nothing "funny" about
   different behaviors when different states exist on the server.

I'll retract my "acts funny" argument, since "acting funny" will never
be more than a subjective criteria.  My real concern was the bad
interaction with versioning (but I still think locknull resources
act funny :-).

This would mean that all locking clients (such as Office 2000) would
fail when applied against a versioned space.  I believe this is
unacceptable (I know it is unacceptable for my implementation).

   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.

But that modification does not have to imply a change that is controlled
by a write lock (the live property analogy).

Cheers,
Geoff