Re: Versioning TeleConf Agenda, 4/19/99
Jeff McAffer OTT (Jeff_McAffer@oti.com)
Mon, 19 Apr 1999 11:09:08 -0400
From: Jeff_McAffer@oti.com (Jeff McAffer OTT)
To: jamsden@us.ibm.com (jamsden),
Message-ID: <1999Apr19.105500.1250.1150452@otismtp.ott.oti.com>
Date: Mon, 19 Apr 1999 11:09:08 -0400
Subject: RE: Versioning TeleConf Agenda, 4/19/99
I have to say that I am on the fence here. My vision of #1 was that you
would start with some set of nodes (i.e., versioned collections) and
snapshot the workspace relative to those nodes. The resulting
configuration would include the transitive closure of all resources
reachable from those original nodes (I called them "roots", Geoff called
this the "scope" I believe). This addresses (I think) part of JimA's
concern regarding the configuration only having one top-level collection.
The ability to add particular revisions to a configuration (i.e., #2) is
interesting. Lets consider the use case of having some resource A and a
workspace which currently would load the "latest" of A which is revision
32. Assume that I decided I want revision 27 to go into some
configuration C that I am building. Given #1 and #2, what are my choices
for doing this?
1) Get revision 27 into an RSR either by explicitly identifying it or by
applying a label to the revision and then adding a label RSR near the
beginning of the workspace's RSR set. Then I snapshot C which has a root
node that (in)directly contains A. Is there an easy way of applying a
label to a bunch of resources (i.e., in one round trip)?
2) Put revision 27 into the configuration C via some configuration
manipulation method. What is this method? Is it the regular collection
add method where the resource added is a URL with a revision id? What
exact form does this take? Note that we would have to be able add many
of these at once.
I do agree with Geoff that enabling #2 allows people to create
configurations with "holes" and that this may complicate the
implementation of the server and diminish the potential for leveraging
"sub-configurations".
Anyway, just some prethoughts for the conference call
Jeff
> -----Original Message-----
> From: jamsden [mailto:jamsden@us.ibm.com]
> Sent: Sunday, April 18, 1999 4:28 PM
> To: ietf-dav-versioning
> Subject: Re: Versioning TeleConf Agenda, 4/19/99
>
> 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
>
>
>
>
>
>