Re: Replacing the Label header with a DAV:labeled-version report

Am Sonntag den, 28. April 2002, um 15:53, schrieb Clemm, Geoff:

> Since this is a fairly significant change, I'd like to
> hear from a few more folks before adding this to the 3253 Errata.

Maybe Greg could comment from subversion's point of view?

//Stefan

> Thanks,
> Geoff
>
> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@greenbytes.de]
> Sent: Saturday, April 27, 2002 5:09 AM
> To: Clemm, Geoff; 'Deltav WG'
> Subject: RE: Label header vs PROPFIND depth 1
>
>
>> From: ietf-dav-versioning-request@w3.org
>> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
>> Sent: Friday, April 26, 2002 6:06 PM
>> To: 'Deltav WG'
>> Subject: RE: Label header vs PROPFIND depth 1
>>
>>
>>    From: Julian Reschke [mailto:julian.reschke@greenbytes.de]
>>
>>    - I'd like to see the label *header* deprecated
>>    - I'm happy with the LABEL method and the label-name-set property
>>    - I think that PROPFIND/label should be replaced by a specific 
>> REPORT
>>
>> Is the proposed DAV:labeled-version report OK with you?
>
> Yes. But I think it's Tim's turn to say whether this would work 
> for him or
> not...
>
>>    - I'm unsure about other methods that are currently affected by the
>>    header -- what were the requirements...?
>>
>> The other methods are LABEL, CHECKOUT, GET, and COPY.
>> For Depth:0 variants of these operations, the Label header
>> just provided an optimization to save one roundtrip
>> (i.e. first getting the version URL via the DAV:labeled-version 
>> report).
>> I believe we can easily do without that Depth:0 optimization.
>
> As stated before, I think that's not the single problem. Having 
> GET return a
> (representation of a) version rather than (a representation of) the VCR
> makes the version *by definition* a variant (representation) of 
> the VCR --
> and it seems that most of us want to avoid that interpretation.
>
>> For Depth:infinity (only relevant for LABEL and COPY), the savings
>> would be more significant, but unfortunately the semantics is broken
>> (since if the namespace is being versioned, you'll get the wrong
>> resources if you simply do a Depth operation on the current 
>> namespace).
>>
>> The Depth:infinity Label header operations are really just a way of
>> trying to have the client fake workspaces and baselines, instead of
>> having the server support them directly.  Since it is much more
>> efficient and reliable to have the server layer these constructs
>> above a labeling infrastructure, rather than having the client do
>> so, I believe the cost of maintaining these Depth:infinity Label
>> header operations in the protocol is not warranted.
>>
>> Note though that (depth:0) labeling and baselining go very well
>> together.  Instead of doing a Depth:infinity LABEL, you can create a
>> baseline (which under the hood the server may well implement with
>> reserved labels, but maybe not), and then LABEL that baseline.  Then
>> when you want to do a Depth:infinity COPY, you retrieve the
>> DAV:baseline-collection of the labeled baseline (using the
>> DAV:labeled-version report), and copy that to wherever you want.
>>
>> Alternatively, if you want a "modifiable" selection, you can create a
>> workspace (which under the hood the server may well implement with
>> reserved labels, but maybe not).  When you want to adjust the versions
>> being selected, you just use UPDATE.  Then when you want to do a
>> Depth:infinity COPY, you just copy from that workspace to wherever you
>> want.
>>
>>    - Servers that decide to implement LABEL and DAV:label-name-set,
>>    but no not support the label header should *not* report the LABEL
>>    feature in OPTIONS.
>>
>> That's probably right.  A client can find out if the LABEL operation
>> is supported by querying the DAV:supported-method-set property values
>> of a VCR.
>
> ....and also use DAV:supported-live-property-set to discover the
> DAV:label-name-set property.
>

Received on Monday, 29 April 2002 03:34:29 UTC