Additional semantics for GET method on VCR

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Additional semantics for GET method on VCR

Werner Donné

Hi,

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.

Best regards,

Werner.
--
Werner Donné  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803 e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Additional semantics for GET method on VCR

Julian Reschke

Werner Donné wrote:
> Hi,
>
> Shouldn't there be additional semantics for the GET method
> when performed on a VCR? Which is the default version that

No.

> is selected? I presume it is either the checked-in version
> or the checked-out resource.

No version is selected at all. The VCR has it's own content. If it's
checked in, it will be the same as the one of the checked-in version.

> ...

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

Re: Additional semantics for GET method on VCR

Werner Donné
In reply to this post by Werner Donné

Hi Manfred,

My question was about what should be in the response entity when
you do a GET on a VCR. As Julian has pointed out, a VCR has its
own content. I've now found that in section 2.2.1.

Regards,

Werner.

Manfred Baedke wrote:

> Hi Werner,
>
>> 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.
> I am not sure whether I understand. What is a default version? Do you
> mean that there should be a GET response header whose value is an URI of
> the checked-in or checked-out version respectively? Why not simply send
> a PROPFIND?
>
> Regards,
> Manfred
>
>

--
Werner Donné  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803 e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Additional semantics for GET method on VCR

Geoffrey M Clemm
In reply to this post by Werner Donné

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.