Next message: Geoffrey M. Clemm: "Re: version selector"
Date: Mon, 18 Sep 2000 11:47:09 -0400 (EDT)
Message-Id: <200009181547.LAA14277@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: version selector
There are three logical constructs involved in versioning:
- a version (a particular saved state of a resource under version control)
- a version history (all the saved states of a resource under version control)
- a version selector (a resource used to access and manipulate the state
of a resource under version control).
The difference between a version and a version history is that one is
a single state while the other is all the states.
The difference between a version and a version selector is that one
always represents the same saved state of the resource under version control,
while the other represents any of the saved states of that resource.
We have at various times tried to "simplify" the protocol by hiding
one of these objects, and require that you get at it by using a header
with a URL to one of the other two (e.g. hide version history and
require that you get at it with a "metadata" header). But that then
required that you needed multiple headers when an operation required
more than one resource (e.g. COPY and MOVE). We further tried to
"simplify" by having the single URL refer to one or the other of the
objects, depending on the method (e.g. MOVE, DELETE, LOCK), but this
just further confused the semantics.
So we ended up by just saying that every resource should have its
own URL, with two remaining headers (Target-Selector, Workspace) just
being being optional ways of making something more efficient or simpler
for the client (Target-Selector avoids 1 round trip, Workspace decreases
the amount of client URL munging).
From: "Jeff McAffer/OTT/OTI" <Jeff_McAffer@oti.com>
Date: Mon, 18 Sep 2000 11:14:58 -0400
I have been lurkingly following the version selector issue on this list
and have a question:
What problem does the notion of "version selector" solve?
It seems to be causing a fair bit of complexity both in the model and the
protocol. It should be adding a corresponding amount of value or it
should be removed.
Note that there is a distinction between adding value to the story and
adding value to the protocol. If version selectors help tell the story
(i.e., define the model), great! That is one way to think of how things
work. It does not mean they have to show up in the protocol.
Jeff