Re: Configurations: A Compromise Proposa
Jeff McAffer OTT (Jeff_McAffer@oti.com)
Fri, 07 May 1999 15:59:55 -0400
From: Jeff_McAffer@oti.com (Jeff McAffer OTT)
To: gclemm@tantalum.atria.com (Geoffrey M. Clemm),
Message-ID: <1999May07.155400.1250.1172615@otismtp.ott.oti.com>
Date: Fri, 07 May 1999 15:59:55 -0400
Subject: RE: Configurations: A Compromise Proposa
I believe you have struck a chord here. We have been trying to do too
many things with one concept (configurations). Your proposal splits the
two in a useful way. I agree with this in general and have a few
observations/questions.
- Just to clarify, I can put a deep or shallow revision of a resource
into a configuration? Putting a deep revision in is basically shorthand
for explicitly adding each of the shallow revisions spec'd in the deep
revision?
- Again, clarification. Baselines/deep-revisions are not
versioned/able-resources, they are a kind of revision of a
versioned-resource. How are deep-revisions identified relative to
shallow-revisions? Do they just have different revision-ids? How do I
(a client) tell if a revision is deep or shallow?
- Nesting of deep-revisions is implicit in that a versioned-colleciton
could (indirectly) "contain" some versioned-resource which could have a
deep-revision. The job of the server when doing a deep checkin is to
ensure that any such nested deep-revisions are valid in the current
workspace. If it is, it can be reused. If not, what? Automatically
create a new deep-revision for that versioned-resource? fail?
- I like the idea of being able to control the content of the deep
revision. I also like being able to deep checkin a collection and get a
depth infinity revision.
- It appears that the "snapshot" operation for creating configurations
goes away? Just so I understand, one creates configurations then by
adding, for example, deep-revisions of versioned-resources (exactly one
per resource) to a configuration?
- I am not particularly happy with the use of the versioned-resource-id
as the member name for revisions explicitly added to a configuration. I
don't know how to fix ti but this is the problem I have talked about
previously where we lose the names of the roots. This seems unnatural to
me. All other resource manipulation metaphors I can think of do not do
this. For example, you don't lose the name of your file when you copy it
to a floppy. The floppy provides a namesapce '/' for retaining the names
of the top level resources. Same in zip files.
- I would propose "deep-revisions" as the property name rather than
"baselines".
> -----Original Message-----
> From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
> Sent: Friday, May 07, 1999 1:03 PM
> To: ietf-dav-versioning
> 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
>
>