Re: PROPFIND, VCRs, Label, Depth, href ... oh my!

On Fri, Feb 02, 2001 at 12:03:04AM -0500, Geoffrey M. Clemm wrote:
>    From: Greg Stein <gstein@lyra.org>
>...
>    Now, let's throw the Depth: header into the mix. What does it apply to? The
>    VCR or the Version? It is murky with the Label: header in there.
> 
> It wouldn't make any sense to apply it to the version, because a
> version is never a collection, but we should make that clear.

Yup. I read up on the Depth: header from RFC 2518, and it seems to indicate
that the processing of the Depth: header is method-specific. Meaning we can
define the meaning of the (PROPFIND, Depth:) tuple, rather than having to
fit into a generic interpretation of Depth:.

[ in short: it appears we can make Depth do what we'd like ]

>...
>        DAV:href returns Version Resource URIs. How do we match them up against
>        the hierarchy defined by the VCRs?
> 
> Well, if your server supports the version history option (which it
> should :-), you can do a Depth PROPFIND (without the label header) for the
> DAV:version-history property, which would pretty much get you what you need.

Hmm. By matching up the version-history properties, I presume?

>    Depth applies to the Version Resource:
>        Presumably, you're selecting a collection version. Its children are
>        version histories, so you're going to get back whacky properties or
>        nothing at all for the children.
> 
> Actually, collection versions are no longer collections (they just

Ah. Right.

>...
>    Okay... let's try to fix the DAV:href thingy by saying you apply the Depth:
>    header to the VCRs (i.e. apply Depth to the VCR before linking thru to the
>    version resources) and the DAV:href returns the VCRs' URIs. That makes some
>    sense, but now we have a problem: how do we get the version resource URI? We
>    can't use DAV:checked-in because that is a VCR prop. And, oh darn! We just
>    nuked DAV:version.
> 
> I think returning the VCR URL in the href would be very misleading.
> Those aren't the properties of the VCR, they are the properties
> of some totally different version resource.

Ah. Good point... PROPFIND on a VCR with and without the Label always
returning the VCR URL... yah... confusing.

>...
>    *) bring back DAV:version
> 
> I think the fact that we would need to bring it back is an
> indication that putting the VCR's URI in the href was a
> bad/misleading thing to do.

Okay.

>    Hmm. I'm thinking that the use of a Label: header is rather spurious to the
>    above issue. It does make it a bit harder to figure out the version resource
>    URI (without the Label:, you could ask for the VCR's DAV:checked-in; there
>    isn't an easy equivalent to find the V.R. when you're trying to use a label)
> 
> Note that using the Label header with Depth is basically bogus anyway
> when you have versioned collections, because you won't be traversing
> the collections that are selected by the label, but rather the
> collections that correspond to the current target of the
> version-controlled collections.  So I wouldn't torque the protocol
> around at all for this.

Hmm. True...

> Bottom line: Labels are for giving a version a human meaningful
> name.  Baselines are for capturing a set of versions.  A server can
> implement baselines with labels, but a client can't, and shouldn't
> try to.

All righty.


The basis for my query here was how to access a baseline by (label) name,
via a version-controlled configuration. I believe the sequence will be:

PROPFIND /some/collection
ask for: DAV:version-controlled-configuration

PROPFIND /the/version/controlled/configuration
Label: the-label-goes-here
ask for: DAV:baseline-collection

further operations on /the/baseline/collection

It would be nice to collapse these via a DAV:expand-property report, but the
Label: in the second request nixes that.

In any case, while thinking about PROPFIND and Label, I was thinking about
the other issues above. (I won't be using a Depth: header, but considering
it threw a wrench into the mix)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Received on Friday, 2 February 2001 02:54:38 UTC