Re: Additional semantics for GET method on VCR

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