W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2000

Re: If: header and "parent" resource checking

From: Greg Stein <gstein@lyra.org>
Date: Thu, 1 Jun 2000 04:23:55 -0700 (PDT)
To: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
cc: w3c-dist-auth@w3.org
Message-ID: <Pine.LNX.4.10.10005311227440.30220-100000@nebula.lyra.org>
[ clarification note: when Geoff says "lock state of the resource", I am
  assuming that he means "the [part of] state in the resource which is
  subjected to write-lock conditions." ]

On Tue, 30 May 2000, Geoffrey M. Clemm wrote:
>    From: jamsden@us.ibm.com
>    <geoff>
>    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.
>    </geoff>
>    <jra>
>    But they're not live properties.
> I didn't mean to imply that they were.  I was just using the way we handle
> live properties as an analogy.  A live property appears to be part of the
> state of a resource, but we allow it to be modified without modifying the
> lock state of the resource.  Analogously, I propose that a lock null resource
> should appear to be part of the state of a collection, but that we allow
> them to be added and deleted without modifying the lock state of the resource.

I see the point and the analogy. However, I disagree that it makes sense
in this context.

Consider the purpose of a locknull resource: to reserve a member within a
collection. If I create a locknull within collection C, then it will
appear within a PROPFIND against C. But that is wrong, when principal P
has taken a lock against C to prevent that very thing!

>    <jra>
>    For example, lock-null resources can be
>    the request-URL of PROPFIND and UNLOCK. The problem is that lock-null
>    resources are only lock-null resources: a bunch of special cases that make
>    sense when you look at them one way and not form another. I think they were
>    a good idea that didn't semantically scale.
>    </jra>
> I agree that lock-null resources are just a bunch of special cases.
> What I'd like to do is minimize their impact on the rest of the
> protocol.  One way to do so is to say that only PROPFIND and UNLOCK
> have to deal with them as a special case, i.e. all other methods do
> not have to treat them as normal resources (in fact, according to
> 2518, most other methods are not *allowed* to treat them as normal
> resources).
> This then means that only the implementation of PROPFIND and UNLOCK
> needs to treat a name lock as if it were a resource.  All the other
> methods do not.  This I believe is the simplest and cleanest way of
> handling lock null resources (and is consistent with what 2518
> currently says).

Euh... they can also be the Destination of a MOVE/COPY. Not sure if that
truly means MOVE/COPY needs to be aware of their special nature, but it
doesn't seem that we can simply shove all knowledge of them into PROPFIND

But, this seems to be a tangent. I consider the original motivation (name
reservation) as the determination for the semantics for a locknull
resource. This means that the parent must allow the name to be reserved,
which means satisfying its locks.


Greg Stein, http://www.lyra.org/
Received on Thursday, 1 June 2000 07:24:17 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:21 UTC