- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 11 Oct 2002 10:03:46 +0200
- To: "Lisa Dusseault" <lisa@xythos.com>, "'Webdav WG'" <w3c-dist-auth@w3c.org>
> From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Lisa Dusseault > Sent: Thursday, October 10, 2002 11:57 PM > To: 'Webdav WG' > Subject: RE: GULP (version 4) > > > "If we get the clarification right"? A definition that involves > discussing > properties, locks, and content in a way that is generic, will result in a > different conclusion for servers that do things differently. The > model can > be 'clarified' for years and still be interpreted differently. Then is hasn't been clarified. If a specification defines locking, but doesn't define what operations on locked resources require submission of the lock token, then in doubt a client always has the choice of submitting the lock token. Servers that don't require it will just ignore it. So where's the big issue with that? > Imagine we try to define a model for what constitutes a state change. > - What if a server, when you issue a DELETE, actually moves a file to the > trash can folder? What if the trash can folder is locked? Clearly, it > requires that lock token. Yes. Bad design. I don't see how anything you are proposing would help with that problem? Either you need the lock token or not. I though the discussion was about the topic on *how* to submit it. Obviously, there always can be hidden server-specific dependencies on other resources that may be locked. If the server wants to enforce these locks, there's obviously no simple way for non-proprietary clients to interact with it. > - What a particular implementation decides that add a file to > /mydir/sub/dir actually changes a property value on /mydir? That would be a computed live property that would better be not lock-protected. If it is, generic clients will have a problem because they won't expect this. > - What if the contents of a file are defined to import the contents of > another file? The server implementation might define that as a content > change. That would be a bug (IMHO). > - Does a collection's members state change if a file is renamed? The state of the collection changes. The state of the member doesn't. > - Does a collection's members state change if a file is overwritten? The state of the collection doesn't change. The state of the member does. > My point is that models are hard to do right. It's very tempting to work on > tweaking the model, when that might not be as effective as simply specifying > exactly what's supposed to happen in a particular case. I think we don't have a choice but to define the model. > In contrast, let's examine another way of "fixing" this problem by putting > additional specification requirements on the server. Rather than say a lock > affects changing state in certain ways (the 'generic' approach), we could > define for each method what locks must be had. For example: > - For DELETE requests, if the DELETE target is locked, or the DELETE target > parent is locked, those locks are affected. > - For COPY requests, if the COPY target is locked, or the COPY target > parent is locked and the COPY target does not exist, those locks are > affected. > - etc. I'd prefer to have a generic model that explains all these requirements, because it would also automatically apply to new methods. However, it surely makes sense -- after getting the generic model right -- to write down what this actually means for all specific methods. The important point is to get the underlying model right first. > Let's go meta for a minute anyway. There are at least two ways that have > been discussed to approach this "problem". One way is to give the client > more leeway. The other is to make things more restrictive for the server - > either through the generic approach of defining state, the specific approach > of describing requests. I don't agree. If you're talking about the "new" header, it doesn't give the client any new freedom. It just allows a simpler syntax. It could use the If header instead. > Client implementers encountering this problem have asked for more client > leeway, NOT for more server restrictions. I consider it perfectly valid to > restate the problem and try to find a different solution -- I do this often > and consider it a good design habit. However, one must always be careful to > make sure one is really solving the right problem when one does this. Yes. But the outcome might as well be that some existing protocol element hasn't been understood properly and already does what the client implementor is asking for. In particular, you *can* use the If header to submit any number of lock tokens you have -- no matter whether they are required or even in effect. If this doesn't work yet in practice, let's clarify the spec and fix the implementations instead of inventing something new. Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Friday, 11 October 2002 04:04:25 UTC