Re: Configurations: A Compromise Proposal
Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Fri, 7 May 1999 10:54:53 -0400
Date: Fri, 7 May 1999 10:54:53 -0400
Message-Id: <9905071454.AA08580@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: jamsden@us.ibm.com
Cc: ietf-dav-versioning@w3.org
In-Reply-To: <8525676A.004C29F3.00@d54mta03.raleigh.ibm.com>
Subject: Re: Configurations: A Compromise Proposal
From: jamsden@us.ibm.com
So a collection could have revisions and baselines?
Yes. (You can think of them as "shallow-revisions" and "deep-revisions").
Revisions would
specify the members of the collection and baselines would specify the
members and selected revisions?
Yes (by "selected revisions", I assume you mean, "selected revisions of
the members of the collection, recursively").
One could add either a revision or a baseline of a collection to a
configuration?
Yes. But you could not add both a revision *and* a baseline of the same
collection (you couldn't, since they would both have the same
versioned-resource-id, and the versioned-resource-id is the name of a
member of a configuration).
The problems are:
1. How does one distinguish between revisions and baselines of a
collection? Do they have different names?
A baseline has a URL, just as a revision has a URL.
Belong to different collections of the versioned resource?
Yes. (At least, that's the way I would model it in the protocol).
Have a property indicating depth?
No. A baseline is always "depth infinity".
Introducing a new concept introduces the need to distinguish it
from existing concepts.
Can't disagree with that! (:-).
2. What does it mean to add a revision of a collection to a
configuration?
It just means that when you look up the member of the configuration whose
name is the versioned-resource-id of that collection, you'll get that
revisions.
That would select members, but the user would have to
have put each member into the configuration too or the configuration
wouldn't select a revision for them and you'd get not found on every
request for a member.
You can either use another configuration (or a label rule, or an
activity, or whatever) to pick the revisions of the members, or
you can explicitly put the appropriate members into the configuration,
or you could put a baseline of those collections into the configuration.
All of these choices are reasonable under different situations.
This is why we did the recursion when putting a
collection in a configuration. Configurations aren't that useful
without it.
You might want to just fix the "namespace" by selecting a particular
set of parent collection revisions, but let activities or labels pick
the leaves. This is actually a fairly common situation where you
don't want people to mess with the namespace, but you are happy to let
them mess with which revision is selected at the leaves (in
particular, this I believe is the behavior Chris was looking for).
3. What's the difference between a configuration and a baseline
collection? Looks like either could be used in a revision selection
rule as they both map versioned resources to revisions.
The fact that two things can be used in a revision selection rule
does not make them the same kind of resource. Labels and activities
can be used in revision selection rules, but I don't think we want
to unify them all into a single concept.
Looks like a
configuration containing one collection and recursively all its
members (whether the user put them in one at a time, or a method did
them all at once) is exactly the same as a baseline of a collection.
True. Just as a label that labels all the revisions that are in
a configuration is exactly the same as a configuration. But configurations
have properties that labels do not have, so it is worth distinguishing them.
The fact that a special case of one construct is similar to another
construct does not make them identical.
In summary, it looks like this solution introduces some issues and
doesn't seem to add very much.
I believe all the issues (at least the ones you've raised so far),
all have straightforward and natural answers.
What it is intended to add, is an answer to the issues that have
prevented us from reaching a mutually acceptable definition of what
a "configuration" is, even after many weeks of effort.
For scalability, I need a construct that is created by a "snapshot
the workspace" operation, and whose members are visible only when
placed into a workspace. In addition, this construct cannot have
"intermediate states" that are visible before the "snapshot" operation
occurs.
For simplicity, others have asked for a construct that just enumerates
the revisions to be remembered. This construct is clearly a superset
of the former construct, but it lacks the key constraints that make
the former scalable.
The proposal suggests that these are two distinct constructs, which have
clear semantics, and which can be combined in very natural ways with the
other constructs that currently exist in the protocol.
What problem does it solve other than
establishing when the revisions are selected? It seems like putting a
single collection in a configuration recursively adding its members
provides the same capability as baseline collections without
introducing a new concept and a new object that has to be
distinguished from collection revisions. I don't see any scaleability
problems with this approach, and it seems simpler than the combined
approach. Am I missing something?
The problem with the "unified" approach is that every time we try to
pin down the details, we end up dividing into two camps, with good
arguments on both side as to which of the two "camps" is right.
Cheers,
Geoff