Re: [Bug 23] lock discovery vs shared locks

On Nov 16, 2005, at 9:27 AM, Julian Reschke wrote:

>
> Lisa Dusseault wrote:
>> On Nov 16, 2005, at 9:16 AM, Julian Reschke wrote:
>>>
>>> Lisa Dusseault wrote:
>>>> I agree there's a fair argument for allowing servers not to put 
>>>> lock tokens in lockdiscovery all the time. I can clarify the text 
>>>> there because there certainly isn't a consensus to require servers 
>>>> to do that.
>>>> We could, however, treat the LOCK (create lock) response slightly 
>>>> differently, and require that the body contains the lockdiscovery 
>>>> property *including* the new lock token -- a special case to handle 
>>>> those clients that had problems at Interop tests.
>>>
>>> This does not make any sense. Sorry.
>>>
>>> It's the "Lock-Token" response header that *always* contains the 
>>> result. Why do you insist on changing the spec so that there's a 
>>> second mechanism?
>>>
>> Because that was the rough consensus at the Interop that year, 
>> amongst the people there, and I don't want to overthrow that too 
>> lightly.  As soon as Cullen declares that there's a consensus for a 
>> single mechanism, I'll edit the spec according to the consensus.
>
> Ultimately, consensus needs to be found in the WG (== the mailing 
> list), not at a meeting. I don't recall any discussion over here about 
> requiring the response body. Did I miss something?
>

I checked back in the email archives, and it looks like there was a 
very closely related discussion which I thought covered it but it 
didn't get into this specific issue.  Naturally consensus needs to be 
found in the WG and I'm sure we can accomplish this.  So are there any 
other opinions on whether the server MUST return the lock token in the 
body as well as the header of a response when a new lock is created -- 
even though we all agree the server doesn't need to normally put that 
info in the lockdiscovery property?

Lisa

Received on Wednesday, 16 November 2005 19:58:13 UTC