- From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
- Date: Wed, 29 Mar 2006 07:44:24 -0500
- To: werner.donne@re.be
- Cc: ietf-dav-versioning@w3.org
- Message-ID: <OF5CB5E560.AFE977BD-ON85257140.0044E421-85257140.0045FB47@us.ibm.com>
I agree with Julian's observation that a VCR has its own content, and that is what is returned by GET, and with Manfred's observation that if you want the content of the checked-in version of a VCR (or of any other version from the version-history of that VCR), you would use PROPFIND to get the URL of the desired Version, and do a GET on the URL of that Version. Note that we did discuss at length the possibility of defining "version selection rules" for a workspace (that would be inherited by all VCR's in that workspace), and have the "checked-in version" of a VCR be dynamically computed, rather than being updated by explicit methods (e.g., CHECKIN, UPDATE, and MERGE). The problem that led us to reject that approach was that no two repositories agree on the semantics for version selection rules, and for performance reasons, it is usually not possible for a repository to support version selection rules that it was not originally designed to handle (so there was no interoperable way for a client to specify versioning rules). The only common denominator we could identify is reflected in the CHECKIN, UPDATE, and MERGE methods (which could be implemented efficiently on the wide range of versioning repositories that we were concerned with). Cheers, Geoff Werner wrote on 03/30/2006 04:59:17 AM: > > Shouldn't there be additional semantics for the GET method > when performed on a VCR? Which is the default version that > is selected? I presume it is either the checked-in version > or the checked-out resource. > > A more advanced possibility could be the notion of a "view > resource", which would be created with the MKVIEW method. > It would contain a set of selection rules, which are a tuple > of VCR path patterns and version URLs (possibly with labels). > The rules would be evaluated in the given order. Methods on > VCRs such as GET could then provide the optional "View" > header, which contains a view URL. Intensive use of versioned > collections would profit from it.
Received on Wednesday, 29 March 2006 12:44:51 UTC