Re: Puzzle: DELETE of a locked collection

On Thu, 13 Apr 2000 jamsden@us.ibm.com wrote:
> <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.

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.

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

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
> also not be such a bad idea to know exactly, and proactively, what you're
> doing when dealing with locked resources.

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.

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

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/

Received on Thursday, 13 April 2000 20:54:18 UTC