- From: Clemm, Geoff <gclemm@rational.com>
- Date: Wed, 12 Sep 2001 16:42:46 -0400
- To: ietf-dav-versioning@w3.org
From: John Hall [mailto:johnhall@xythos.com] In Xythos first generation server, locking a VCR locks the VHR and all VERSIONS. DeltaV defines these as completely different resources, and it has been previously mentioned that they should be locked independently. Yes, it is fine for your client to present a model to the user that a lock on a VCR also locks the VHR, but to be compatible with the protocol, that should be marshalled as two LOCK requests, one to the VCR and another to the VHR. A VHR is not appropriately a target of a PUT or a PROPPATCH on my system. What meaning could they have? A PUT is undefined on a VHR (just as PUT is undefined on a collection and an activity). PROPPATCH is meaningful ... it gives the VHR a property (DAV:displayname, or some custom property). Note that we have been told that in order to support global properties we should have people do a PROPPATCH on the VHR. The way this would work is that your GUI would display both the properties of a VCR as well as the properties of the VHR, thus effectively displaying the VCR as "inheriting" the properties of its VHR. You would have to make some decision about what to do in the case of conflicts (i.e. when both the VCR and VHR have the same property with different values). A client would be responsible for deciding whether a the property is a "global" (on the VHR) or "local" (on the VCR) property (assumedly based on some GUI gesture from the user). In my model of how that would work, the real resource being modified is the VCR and all versions of the file -- not the VHR -- and a PROPFIND on the VCR should see the global properties. If the VCR is locked, a PROPPATCH that modifies its state should fail. Your client can present any model that it wants, but to interoperate with multiple servers, it needs to adhere to the DeltaV semantics, in which the VCR and VHR are separate resources with their own locks. Similarly, your client can do whatever it wants in terms of displaying a global property model, but to provide an interoperable form, it must use DeltaV/WebDAV compatible requests (such as modeling global properties as properties of the shared VHR). It has been pointed out to me that this was probably not what the list meant. If such properties (set on the VHR) were not visible on the VCR and you had to access the VHR to get them then someone implementing that should allow a lock on the VHR. However, in that case I wouldn't see 'setting VHR properties' as being a way to implement global properites. I'd drop my plans to support PROPPATCH on the VHR, hence the reason to lock the VHR. Therefore, I see no reason why a VHR should be locked independently of a VCR. Either the operation is moot, or (in the case of guidance we have received on global properties) the proper lock is on the VCR not the VHR. I agree that being able to lock a VHR is of neglibible value. Someone might decide to implement global properties by placing them on the VHR, in which case being able to lock a VHR would be of value to that client, but not a very compelling use case for me. Next, we have past versions. Past versions are not mutable (there goes PUT and PROPPATCH). A non-forking server such as mine does not allow past versions to be checked out. LABEL isn't supported, but is LABEL supposed to honor a write lock? I'm not so sure. See section 1.8, Versioning Methods and Write Locks: If a write-locked resource has a non-computed property defined by this document, the property value MUST NOT be changed by a request unless the appropriate lock token is included in the request. Since every method introduced in this document other than REPORT modifies at least one property defined by this document, every versioning method other than REPORT is affected by a write lock So yes, labels are controlled by write locks, but since the LABEL method gives you incremental add/delete capability, there is little or no reason to "lock" the version for a LABEL request. So I see no reason to support a LOCK on a past version. I agree. Locking a version is even less likely/important than locking a VHR. A CHECKOUT creates a 'state that can be modified'. In the case of Checkout-In-Place, that is logically the VCR. I'm told that there shouldn't be a real version in this case that can be accessed independently of the VCR. Again, only a VCR lock makes sense. I agree. Locking a VCR is the prime locking use case. Yes, I note that I must provide for a lock on a working resource. Yes, although since a working resource has an obscure URL, it is unlikely that anyone will try to use your working resource, so locking is probably not all that important for working resources. I'm just trying to find a reason whey I should allow it anywhere else. I'm not seeing one. If you only handle locking of a VCR, I believe you will handle 98% of the important use cases. Cheers, Geoff
Received on Wednesday, 12 September 2001 16:43:31 UTC