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

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.

Cheers,
-g

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

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:54 GMT