Re: [Bug 23] lock discovery vs shared locks

Our existing code only uses LOCK to (1) get a new exclusive lock and  
(2) to refresh the exclusive locks we own. We parse the lockdiscovery  
response for a lock-token in both cases. I looked through the various  
versions of our code and I *think* that it wouldn't matter if the  
lockdiscovery response were not returned in the LOCK refresh  
response, but without a server to test against, I cannot be sure.

So I agree with Geoff, but would add the requirement of returning the  
lockdiscovery response for a LOCK refresh because it would be useful  
for the same reasons you'd want the lockdiscovery response when a  
lock is created (to get the locktoken, timeout value, etc). This  
should not be a lock privacy problem because the client has proved it  
knows about the lock via the If header in the request.

- Jim

On Nov 18, 2005, at 9:31 AM, Geoffrey M Clemm wrote:

>
> From a lock privacy perspective, putting all information about the
> newly created lock in the lockdiscovery response to a LOCK
> request is (of course) no problem, so requiring that is fine with me.
>
> Perhaps the new text could require that full information about a LOCK
> be returned in the lockdiscovery response to a LOCK, while information
> about other locks is optional in the lockdiscovery response to a LOCK.
>
> Cheers,
> Geoff
>
> Julian wrote on 11/18/2005 12:06:21 PM:
> >
> > Geoff, any input about how a server concerned with the privacy of  
> lock
> > information would return the actual timeout value (as compared to  
> the
> > one sent by the client)?

Received on Friday, 18 November 2005 18:24:33 UTC