W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2001

Re: Proposed Simplifications to the DeltaV protocol

From: Greg Stein <gstein@lyra.org>
Date: Mon, 26 Mar 2001 22:44:37 -0800
To: ietf-dav-versioning@w3.org
Message-ID: <20010326224437.R27539@lyra.org>
On Tue, Mar 27, 2001 at 12:40:51AM -0500, Clemm, Geoff wrote:
> The consensus of the room at the DeltaV working group session was that
> we should remove the Label header, to avoid this internationalization
> problems.  Since the Label header is an optimization (i.e. you can use
> PROPFIND to determine the information), this was considered the
> appropriate response to the area directors concern.  Note, the proposal
> is not to remove the LABEL method, just to remove the Label header.
> Any objections?

Hmm. I believe that I do. In my particular scenario, I have a VCC and need
to PROPFIND one of many baselines, using a Label as the selector. Without
the Label header, I'd have to PROPFIND every single baseline to find the
right one, wouldn't I? Is there something that I'm missing?

Assuming that I haven't missed something, then yes: I would object. I can't
see how to create similar functionality in other ways.

>... defer the Variant Option ...
> Any objections?

Deferral is fine with me. I have no interest in this, and I honestly don't
see it as a useful feature for any versioning server. (IOW, with my personal
hat on, and my independent hat on, I see no/little utility)

> The third proposed simplification was to defer the "Update Option",
> with the intention of leaving it out of the protocol unless its
> addition is more strongly motivated than it is currently.  In
> particular, if you want to expose an older version of a VCR, you can
> just check out that VCR, copy that older version into the checked-out
> resource, and then check it back in.  This has the added advantage
> that this does not block future work on a linear versioning server,
> the way an UPDATE would (i.e. you can only check out the tip in a
> linear versioning server).  It also has the advantage that it is more
> compatible with the baseline and activity features, that want to
> define states as merges of baselines and activities, rather than
> manipulations of individual versions.
> Any objections?

I'm not sure about the proposed workaround (that appears to alter the tip,
rather than expose an older resource), but I see little use for the
UPDATE method, too. Consider: if you have a VCR that you intend to point at
an old version for a long period of time, then why not just give out the
version resource URL to begin with? 

A server could also use bindings to establish a collection of older items.
You could use baselines. Lastly, you could expose a workspace that has been
smacked with MERGE to point at old resources.

IOW, I tend to see VCRs as always floating to the latest. Tweaking their
value (other than as part of a checkin) seems of little utility.

I'm happy to defer/punt the feature.

>... folding branch control into the core ...
> Any objections?

Totally fine. That isn't a big change/imposition.

>... packages ...
> client workspace configuration management:
>    core
>    version-history
>    working-resource
>    merge
>    label
>    baseline
>    activity
>    version-controlled-collection

Hey! That looks like Subversion :-)

> Any objections to these packages?



Greg Stein, http://www.lyra.org/
Received on Tuesday, 27 March 2001 01:44:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:46 UTC