Re: Configurations: A Compromise Proposal
jamsden@us.ibm.com
Fri, 7 May 1999 09:51:22 -0400
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <8525676A.004C29F3.00@d54mta03.raleigh.ibm.com>
Date: Fri, 7 May 1999 09:51:22 -0400
Subject: Re: Configurations: A Compromise Proposal
Geoff,
This is where we were headed as the result of our meeting in Cary. I think there
are some issues with this approach that bothered me then, and might still now.
First a couple of questions:
So a collection could have revisions and baselines? Revisions would specify the
members of the collection and baselines would specify the members and selected
revisions?
One could add either a revision or a baseline of a collection to a
configuration?
The problems are:
1. How does one distinguish between revisions and baselines of a collection? Do
they have different names? Belong to different collections of the versioned
resource? Have a property indicating depth? Introducing a new concept introduces
the need to distinguish it from existing concepts.
2. What does it mean to add a revision of a collection to a configuration? 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. This is why we did the
recursion when putting a collection in a configuration. Configurations aren't
that useful without it.
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. 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.
In summary, it looks like this solution introduces some issues and doesn't seem
to add very much. 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?
"Geoffrey M. Clemm" <gclemm@tantalum.atria.com> on 05/07/99 06:23:12 AM
To: ietf-dav-versioning@w3.org
cc: (bcc: Jim Amsden/Raleigh/IBM)
Subject: Configurations: A Compromise Proposal
Jim, Sankar, Chris, and others have made a good case for having a simple
"collection" style configuration, where revisions are explicitly
added and removed by a client. Jeff and I are firm believers in
"a deep revision of a collection" as the approach that is also
simple (in a different way) and scales up to handle large configurations.
I think this is a case where "we're both right". These are two distinct
approaches with different advantages, and our current attempt to force
them into a single resource-type may be a mistake. So I'd like
to propose the following:
----------------------------------------------------------------------
A "configuration" is just a "a collection of revisions". The user
uses standard advanced collection protocol to add and remove revisions
from this collection. The name of a member of a configuration is the
"versioned-resource-id" of that revision. This guarantees that at
most one revision of a versioned-resource can be a member of a given
configuration. (Note: there is no "recursively adding members of a
collection" semantics -- the only constraint on the revision set is
one revision per versioned-resource).
A "baselined-collection" is a special kind of "versioned-collection"
which has a "baselines" property in addition to the "revisions"
property that all versioned-resources have. The "baselines" are the
"deep revisions" of the collection, while the "revisions" are the
standard "shallow revisions". A new revision of a baselined-collectin
is created in the standard way with a CHECKIN operation. A new
baseline of a baselined-collection is created by adding a "Baseline"
(or perhaps "Deep") header to the CHECKIN request. A
"Baseline CHECKIN" creates a new baseline of a baselined-collection
that contains the revisions of the members of the baselined-collection
that are currently selected by the Workspace.
----------------------------------------------------------------------
A configuration is then the simple "set of revisions" that Jim, Sankar,
Chris, et. al. have advocated. A baselined-collection provides the
deep-revision semantics Jeff and I have advocated. These two concepts
fit nicely together, in that adding a baseline of a collection into
a configuration lets you mix and match deep revisions just as you would
mix and match shallow revisions.
This also gets back to a question that was raised in the design meeting
about 7 months ago about whether a revision of a collection was deep
or shallow ... the answer would now be "we support both".
How does this sound?
Cheers,
Geoff