- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 07 Dec 2004 11:50:53 +0100
- To: Lisa Dusseault <lisa@osafoundation.org>
- CC: Webdav WG <w3c-dist-auth@w3c.org>
Lisa Dusseault wrote: > On Dec 6, 2004, at 2:20 PM, Julian Reschke wrote: > ... > Clever... so an observant client could detect that the same lock > existed on two URLs so conclude they are bindings to the same resource > (unless the server calculates the value for lockdiscovery on the fly > and does something unlikely and weird with lock tokens). If a server does something "unlikely and weird" that causes this not to work, then it's broken. There's no reason to believe that a server that get's DAV:lockdiscovery wrong will get DAV:resource-id right, so why would I worry about that? > I still think that the bindings draft makes it far more likely that a > client will try to detect whether two bindings are the same resource > and behave differently if they are. For example, a client that is > bindings-aware could try to speed up synchronization by using > 'DAV:resource-id' and synchronizing only once per resource, rather than > once per binding. The client could cache the 'DAV:acl' property (or > any other live property) for offline use. If the client knows that all > bindings will have the same value for 'DAV:acl' then it only needs to > request that property once per resource. OTOH if the client knows that > different bindings may have different values for 'DAV:acl' (or another > live property) then the client must ask once for each binding. Which is exactly the reason why RFC3744 says that DAV:acl will be the same no matter what binding you use. > I also worry that it's not enough for us to say that dead properties > MUST be the same value no matter which binding is addressed but live > properties MAY vary. We don't have a reliable way for the client to > tell which properties are dead and which are live. Still, I could live > with that. Well, as you just pointed out, the difference between dead and live properties is fuzzy. Also, the statement as proposed, sort of *encourages* implementers to have live properties varying by binding. IMHO, they shouldn't (as properties are part of the state of the resource or computed based on the state of a resource), and thus should not vary at all. My impression from earlier discussion was that you don't buy that point of view, so I haven't tried hard to get it into the spec. Should I now? Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Tuesday, 7 December 2004 10:51:29 UTC