Re: [Bug 23] lock discovery vs shared locks

Lisa Dusseault wrote:
> 
> Julian, do these data points affect your conclusion?

This kind of proves how important it is to first clearly understand the 
problem, and to document it, and only then to think about spec changes.

So I've gone back to the good old approach to actually run tests on 
existing servers (test script attached) and clients.

Things I've been looking for:

1) Is the Lock-Token header returned upon LOCK?

2) Is the lockdiscovery property returned?

3) If the lockdiscovery property is returned, does it only contain the 
new lock token, or also other tokens (of shared locks)?

And, while testing, I came across some more issues:

4) Are lock tokens correct?

5) Does PROPFIND/lockdiscovery work as expected on resources with 
multiple shared locks?

Results:

SAP Netweaver KM: 1) yes, 2) yes, 3) contains all, 4) yes, 5) yes

Apache/moddav: 1) yes, 2) yes, 3) only the newly created, 4) yes, 5) yes

IIS6: 1) yes, 2) yes, 3) only the newly created, 4) yes, 5) no (returns 
multiple property instances)

Xythos: 1) yes, 2) yes, 3) contains all, 4) no (uses opaquelocktoken, 
but not the correct syntax), 5) yes


Summary:

S1) all servers tested return the Lock-Token header

S2) all return the <lockdiscovery> property, but with differences when 
there were multiple locks (naturally I claim that "contains all" is the 
right answer)

S3) one server still does not get lock tokens right

S4) one server doesn't get lock discovery in presence of multiple locks 
right


Next steps:

re S2) decide what's right; noting that it really doesn't matter if we 
tell clients just to use the Lock-Token response header; so why not 
remove the stuff about <lockdiscovery> response bodies?

re S3) I hope the developers are reading this :-)

re S4) I'll open a bug report.



On the client side I only tested what happens if Microsoft Office tries 
a lock, but doesn't get the <lockdiscovery> response body. This led to 
Office thinking the lock did not succeed, opening the document 
read-only. I'll open a bug report for that one as well.


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.

Best regards, Julian