RE: If: header and "parent" resource checking

Just to follow-up on this thread from a versioning perspective:

There are other reasons to allow "private" members of a versioned
collection (i.e. members that can be added/deleted without checking
out the versioned collection, or remembering the members in the
history of the versioned collection), so with this as additional
motivation, I've proposed that the versioning protocol support the
notion of "private" members of a versioned collection, and used
lock-null resources as one of the motivations.

So assuming that "private members of versioned collections" passes
muster with the versioning design team, I have no problem with the
current 2518 model that Greg (and others) have proposed to support.

Cheers,
Geoff

-----Original Message-----
From: Greg Stein [mailto:gstein@lyra.org]
Sent: Thursday, June 01, 2000 7:24 AM
To: Geoffrey M. Clemm
Cc: w3c-dist-auth@w3.org
Subject: Re: If: header and "parent" resource checking


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