Re: configurations and snapshots
Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Tue, 6 Apr 1999 00:42:38 -0400
Date: Tue, 6 Apr 1999 00:42:38 -0400
Message-Id: <9904060442.AA27543@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: ietf-dav-versioning@w3.org
In-Reply-To: <1999Apr01.131800.1250.1132781@otismtp.ott.oti.com>
Subject: Re: configurations and snapshots
> From: Jeff_McAffer@oti.com (Jeff McAffer OTT)
> - Can I spec an RSR to use the "latest" revision of a configuration?
The protocol currently has no such rule. But servers are free to extend
the RSR elements if the standard RSR elements do not suffice for their
needs (at the potential cost of non-interoperability with servers that
don't support those extended RSR elements).
The choice of what RSR elements go into the base spec will be a
delicate balancing act. We want enough in there to capture the
"common" RSR elements that clients and servers are likely to support,
but not so much that it is unreasonable to expect any server to
support more than a small subset.
So putting too much in will mislead clients into thinking they can use
something that most servers will not in fact support. Putting too little
in does not allow clients to take advantage of common server functionality.
> If no, why not?
Because this is not a commonly supported/supportable RSR element, so
it would be misleading to make clients think it was. In particular,
many servers will cache the often large mappings implied by a
configuration. It would be prohibitively expensive for
many/most existing (even high-end) servers to check the state of every
configuration used in its revision-selection-rule (in order to see if
there is a "later" one), before every request to a versioned-resource.
> - If yes, would that be called "putting a snapshot into the RSR?"
No. "Putting a snapshot into the RSR" means putting a specific configuration
revision into the RSR.
> If so,
> "snapshot" does not refer to a specific configuration revision and the
> terminology is inconsistent.
Right, that's why the answer was "no" (:-).
> We may as well say "put a configuration in
> the RSR" and have it be understood that you can put a particular revision
> there or just leave it be the latest.
Yes, that's why it is very important to have a specific term for a
configuration revision, so no such misunderstanding takes place.
> A fundamental question that keeps coming back to me is "how do we deep
> version collections?". Has there been agreement on this?
No. It's not that there is no agreement, but rather that we haven't
discussed it much yet. The clemm-webdav-versioning document does have
one proposal for how this could be done.
> Here are some
> assumptions. Please correct me where I am wrong ( as I am sure I am):
> 1) There is no effective way of deep versioning a collection without
> using configurations.
Correct.
> 2) Configurations capture the entire state of a workspace
No, a snapshot captures the subset of the workspace state defined
by the DAV:scope of the snapshot.
It is very important to distinguish a *snapshot* of a versioned-collection
(which is a set of revisions) from a *revision* of a versioned-collection
(which is the set of versioned-resources that are the *immediate*
members of that collection). In particular, a snapshot of a
versioned-collection will contain exactly one revision of that
versioned-collection, as well as one revision of every versioned-resource
that is a member of that versioned-collection revision.
> 3) Users do not always want to version all the resources on which they
> are working
True. Non-versioned resources are visible in workspaces, but
are not be captured by snapshots (since snapshots are user-URL to
revision-URL mappings).
> If these are all true then we are going to have a lot of workspaces.
> People (tool builders) are going to end up creating workspaces for every
> collection of resources on which they want to support versioning in an
> independent way. Untenable from both perspectives.
Luckily, the aren't all true, so we don't need to have a lot of
workspaces (:-). A workspace lets you see revisions and non-versioned
resources. Only a snapshot is limited to just revisions.
> If configurations are some resource to which I can add and remove
> elements then I can build a config taht contains only those portions of
> the workspace in which I am interested.
You can do the same things with labels and a label RSR element, so you
don't need configurations to do this. Alternatively, you can make
snapshots whose DAV:scope limits them to those portions.
> Cool but this would be somewhat
> laborious if I wanted to version a large subtree and I had to add each
> node individually. How do people see this working in real life?
In real life, you have an RSR (revision-selection-rule) that says
something like "my-activity ELSE snapshot-beta-1.3" or "my-label ELSE
snapshot-beta-1.3". This revision selection rule picks out both
revisions of versioned-collections, and revisions of the basic
(i.e. non-collection) versioned-resources that are in those
collections. When you are happy with the state of your workspace,
you can issue a "make-snapshot" request, creating snapshot-beta-1.4,
which you can now use in a revision-selection-rule.
A smart server can create snapshot-beta-1.4 very efficiently, by
only storing the delta (i.e. the current state of "my-activity" or
the current state of the incremental label, "my-label").
Great set of questions!
Cheers,
Geoff