Re: Versioning TeleConf Agenda, 4/19/99 (Monday) 2-3pmEST
jamsden@us.ibm.com
Sun, 18 Apr 1999 16:24:09 -0400
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <85256757.007022D3.00@d54mta03.raleigh.ibm.com>
Date: Sun, 18 Apr 1999 16:24:09 -0400
Subject: Re: Versioning TeleConf Agenda, 4/19/99 (Monday) 2-3pmEST
I think both concepts must be supported. The more general notion of a
configuration is that you create one, and add the things to it that you
want in the configuration. This is just like a specialization of a
collection containing only references to revisions. As with any other
collection containing references, it provides a convenient way to collect
reused resources, and adds the additional behavior of allowing a fixed
revision to be specified that can later be used in a workspace, something a
collection can't do. Case *1* sounds similar, but the notion that a
configuration is different than a collection is missing. These semantics
are too important to hide in a collection.
But for case *2* to work, adding a collection to a configuration must
recursively add all its members. This is the only thing adding a collection
to a configuration could mean. So *1* is just a special case of *2* where
the configuration only has one member, the top-level collection added.
I would generally prefer user flexibility over server implementation
flexibility anytime, and I think its a little premature to worry too much
about efficient server implementations. Not that this is not important,
just that we should think about the user first. Optimizing space or
performance before something is designed and working has proven to be
generally very ineffective.
A deep header on CHECKIN to create a configuration seems like a heavy
overload to me. Better to separate concerns. We don't need to optimize the
protocol with minimal methods. It doesn't buy anything and may introduce
complexity due to the overloads and conceptual coupling.
So I agree with Geoff, we need both *1* and *2*, and they are not
alternatives, but part of a consistent set of configuration semantics.
"Geoffrey M. Clemm" <gclemm@tantalum.atria.com> on 04/18/99 11:26:15 AM
To: ietf-dav-versioning@w3.org
cc: (bcc: Jim Amsden/Raleigh/IBM)
Subject: Versioning TeleConf Agenda, 4/19/99 (Monday) 2-3pmEST
phone: 888 819 8909 pass-code#97985
Agenda:
- Configurations and Snapshots
This remains the major unresolved item on our list. I think we are
getting closer though. I believe there are currently two main positions
being held:
*1* A "deep revision" of a collection is both necessary and sufficient
to support the configuration use cases. For now, I'll just use the
term "baseline" for this concept. To create a baseline of
a collection, you select a workspace and "snapshot" the set of revisions
that are currently selected as the members of that collection in that
workspace. A baseline of a collection contains both revisions and
"sub-baselines", to allow the cheap creation of new baselines through
the re-use of existing sub-baselines.
*2* A more general "revision collection" is needed, in which the only
constraint is that it can contain at most one revision from a
particular versioned resource. The primitive operations on a revision
collection are just "add member revision" and "remove member revision".
Those of us that support the first position believe that the arbitrary
"add-member" and "remove-member" operations do not give the server the
flexibility it needs to cheaply implement configurations, especially
configurations of large numbers of revisions.
Those of us that support the second position believe that the more
general notion is required to reflect what common versioning systems
do today.
I personally hold to the first position, but I could live with a
compromise which provides both concepts, i.e. "baselines" for deep
revisions of collections, and "configurations" which provide the
more general "revision set" concept.
As a protocol note, it would be tempting to just implement "make-baseline"
as just a "Deep" header for the CHECKIN operation.
Cheers,
Geoff