W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2005

Re: [Bug 23] lock discovery vs shared locks

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 18 Nov 2005 18:06:21 +0100
Message-ID: <437E0A0D.6070209@gmx.de>
To: Lisa Dusseault <lisa@osafoundation.org>
CC: webdav WG <w3c-dist-auth@w3.org>

Lisa Dusseault wrote:
> 
> This is great data Julian, very useful.
> 
> On Nov 18, 2005, at 8:52 AM, Julian Reschke wrote:
> 
>>
>> Proposal:
>>
>> 1) Describe lock token discovery after successful LOCK in exactly one 
>> place in the spec, and make sure examples are correct
>>
>> 2) Remove the requirement to return the <lockdiscovery>, and mention 
>> that change in the "changes" section, including rational and suggest 
>> servers continue to return it when backward-compatibility with older 
>> clients is an issue.
>>
> What about clients learning the lock timeout?  I know some clients use 
> the <lockdiscovery> in the response body to learn what timeout the 
> server chose, and use that to know when to refresh the lock.

Good question, for which I don't have an answer. We *could* state that 
the <lockdiscovery> response indeed is *not* the same as a 
<lockdiscovery> property, and require servers to return complete 
information just for the newly created lock. That would require a change 
in the shared lock support in SAP KM and in Xythos, but I guess both 
parties could live with that.

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)?

Best regards, Julian
Received on Friday, 18 November 2005 17:07:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:11 GMT