RE: refresh LOCK for multiple locks

On Fri, 26 Nov 1999 ccjason@us.ibm.com wrote:
>   If you mean locks implied by a Tagged-List in the If: header, then that
>   just doesn't make sense :-)
> 
> That's what I meant.  I don't know if it makes sense or not, but I'm
> perfectly willing to say that "it" is not supported.

Hrm; I guess it could make some sense to impute the URIs in a tagged-list
as some kind of input parameter. We do with the locktokens, after all :-)

> And I agree that it seems somewhat odd that we use the IF header to
> determine
> what locks are to be refreshed.  I would think this should work just as
> UNLOCK
> does.  That's not to say people can't use an IF header, but that's not how
> they specify which of the locks is to be refreshed.  The IF header would
> only
> be for consistancy checking if the client wanted the refresh to be
> contingent
> on the presence of a specified lock on some specified resource.

IMO, this would have been the clearest way to do this. It's that pedantic
trap again. As JimW explained "well, we saw it as a precondition, and
preconditions are specified with the If: header, and ..."

> Now I also recognize that changing this might break some clients/servers.
> Before we could change this,
> we'd have to come to a consensus that we're willing to change our
> implementations.

Well, Office 2000 uses LOCKs and could be argued as one of the more
popular clients :-). If it doesn't send a Lock-Token header, then we're
out of luck. The spec would then need to specify behavior in the absence
of the Lock-Token header. Anybody know if it sends a Lock-Token header
when it refreshes its lock?

Personally: I'd be fine changing mod_dav. Simply a lot of stuff, and I
really think its the clearest mechanism for the protocol.

Cheers,
-g

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

Received on Friday, 26 November 1999 15:13:31 UTC