RE: Interop issue: Proposal for fixing lock token provision

> From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On
> Behalf Of Seth Osher
> Sent: Wednesday, October 09, 2002 5:54 AM
> To: Webdav WG
> Subject: RE: Interop issue: Proposal for fixing lock token provision
>
>
> For example a long running folder copy, move or delete.
>
> If the operation takes long enough that locks might expire
> during the operation, then the semantic might not even be
> really enforceable. Particularly, it servers is incapable of checking the
> locks in advance, or to do so might be expensive from a time
> perspective (say an operation on a optical-archive, where the full set
> of resources is only known on the media).

...in which case I'd say that the locks should have had a longer timeout in
the first place. Why bother locking, if you're unsure that the timeout is
long enough to protect the subsequent request?

> In these cases you want the copy or move to perform "as much work
> as possible" so you just want to provide a list of all your
> current tokens.

Really? Again -- if it's irrelevant whether the lock is still there, why was
it made in the first place?

> A second example is where a server provides multiple views of the same
> data.  A client may not know for certain what resources it has locked
> and are going to participate in a copy, move or delete operation.
> Rather than fully enumerating the set of resources to be operated on,
> presenting "all-my-tokens" would be useful, if not critical.

I don't understand this scenario. Could you please define what a "view"
technically is on your system? Is it an additional binding to the same
resource?

Every lock that the client made has been made on a particular request URI --
and that's the URI that needs to be submitted alongside with the lock token
(in the If header).

> A third case is where a user wants the operation to succeed, even
> if etags for the locked resources have changed (perhaps a shared-write
> has updated the resource, changing its etag).  In this case, we want to
> present the lock, and don't want to worry about the etag.  It might even

Why do you submit the etag if you don't want it to be enforced?

> have be deleted by the shared-write lock so the token is no longer valid.

Why would the resource be deleted if you still have a shared-lock on it?

> Perhaps it is possible to construct an If: header that handles these
> cases, but a shorthand that avoids recursive introspection on the server
> would be useful, particularly in low-bandwidth environments.

As shown in yesterday's mail, it is possible. It's just syntactically
different.

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Wednesday, 9 October 2002 04:40:29 UTC