Subject: Re: Puzzle: DELETE of a locked collection

From: [email-masked]
Date: Thu, 13 Apr 2000 20:36:16 -0400

<greg>
*) if a tagged-list state-list specifies a URL and its locktoken, then the
   state-list will be applied to the internal members (to the extend of
   the lock depth). this will effectively replicate the state list down to
   all affected members.
   (any existing tagged-list for an internal member will override this
    implied state-list)
</greg>
<jra>
I think this is a bad thing as it will result in lots of confusion about
what token is supposed to match with what resource. It is possible that
this will result in overwrite conflicts when applied to depth locks on
collections.

I think the If header does work as I suggested in a previous email. You'll
have to know the members that are to be targeted by the tag list ahead of
time, and suffer the inconvenience of putting them all in a potentially
long If header, but computers are good at handling such things. It might
also not be such a bad idea to know exactly, and proactively, what you're
doing when dealing with locked resources.

But I'm happy to use the Lock-Token header for lock tokens too. I think it
will have similar problems though. The problem is really with those pesky
depth locks.
</jra>

---

From: Greg Stein <[email-masked]>
Date: Thu, 13 Apr 2000 18:00:20 -0700 (PDT)

> this will result in overwrite conflicts when applied to depth locks on

Sorry, but this whole thing is confusing in the first place. Moreover, the
spec simply states that I need to pass along the proper lock tokens. It
says nothing about associating those tokens appropriately with each
resource that I'm going to modify.

Further, I don't see the possible overwrite conflict you're talking about.
The algorithm that I stated above simply says that File1..N (from my
example) will implicitly have an assertion about Token B. Not Token A.

> long If header, but computers are good at handling such things.

I refuse this concept absolutely. There is no way that I will force a
client to know all members recursively before they issue a DELETE of a
locked collection. That is positively ridiculous.

It is no big deal, though. I've already found other mechanisms that work
around the current specification. To eliminate this "nasty work around",
it looks like there is a consensus building for a Lock-Token header that
contains the union of all tokens in the affected resources.

> It might

I think it's a bad idea, and I'll advocate that clients use one of the If:
header hacks that I've posted, rather than delineating all members.

Heck, it seems like I recall hearing that some proxies even have limits on
the size of the headers that they will process.

> will have similar problems though. The problem is really with those pesky

Partly. It is also partly caused by an unclear spec. We've been assuming
that you must associate the locktoken with the appropriate resource. This
isn't necessarily true.

Of course, a person *does* want to assert they still hold a lock on a
particular resource when they do an operation, so a Tagged-list is usually
a good idea. But they can handle that with:

If: <Collection> (<A>)
    <SubCollection> (<B>)

In this case, none of the productions will match File1..N, so the If:
header assertions are ignored for those resources. But: the necessary
tokens for File1..N is present (B), so the operation succeeds.

Cheers,
-g

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