Re: Versioning TeleConf Agenda, 5/3/99 (Monday) 2-3pmEST
jamsden@us.ibm.com
Mon, 3 May 1999 15:26:43 -0400
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <85256766.006B3164.00@d54mta03.raleigh.ibm.com>
Date: Mon, 3 May 1999 15:26:43 -0400
Subject: Re: Versioning TeleConf Agenda, 5/3/99 (Monday) 2-3pmEST
Geoff,
I substantially agree with the functionality you specify for configurations, but
not the implementation. I think we should reuse collection semantics to specify
members of a configuration. I also don't think we need to introduce the notion
of a snapshot. Comments are mebedded below.
"Geoffrey M. Clemm" <gclemm@tantalum.atria.com> on 05/03/99 10:49:37 AM
To: ietf-dav-versioning@w3.org
cc: (bcc: Jim Amsden/Raleigh/IBM)
Subject: Versioning TeleConf Agenda, 5/3/99 (Monday) 2-3pmEST
phone: 888 819 8909 pass-code#97985
Agenda:
- Configurations and Snapshots
I believe we are close to finishing this topic (one can always hope :-).
In particular, I believe the following proposal captures the current
thinking on the topic:
* a configuration is a versioned-resource
* a revision of a configuration is called a snapshot -- why isn't it just a
configuration revision?
* a snapshot has a DAV:scope property containing a list of URL's. -- sounds like
implementation. Why not have it be the members of a collection as that's a list
of URLs too?
* the DAV:scope property can be modified in a checked-out configuration -- the
members of a checked out collection can be changed.
* a snapshot has an associated list of revisions, specified at CHECKIN time
by selecting a revision of each URL in the DAV:scope, and a revision
of each internal member of each versioned-collection revision in the list.
* the revisions associated with a snapshot are selected from the current
workspace.
Here's my proposal:
- a configuration is a specialization of a WebDAV collection - therefore it is a
versioned resource.
- the member URLs of a configuration are mapped to specific revisions of
versioned resource. (There is some question as to whether mutable revisions
and/or unversioned resources can be members of a configuration. Since
configurations are collections, we can decide this or not without any
significant change in the overall semantics.)
- each member of a configuration is recursively mapped to a revision. That is,
when a collection is added to a configuration, its members are recursively added
to the configuration.
- the revision selected is either given by a workspace, or by explicit
selection, using a label (or activity or another configuration?)
- in the simplest case, the revision selection could be done when the
configuration member is added. However, this introduces a possible for error if
the workspace RSR changes, or the label moves to other revisions as a
potentially inconsistent set of revisions may be added to the configuration. To
avoid this problem, the revision selection could be done for all members when
the configuration is checked in.
I believe the major unresolved issue is how to provide a "lightweight"
way of producing new snapshots, for clients that just want to say
"take the predecessor snapshot but use these particular revisions instead".
I believe that an interoperable way of achieving this is to have
such a client checkout the configuration into a "configuration workspace",
enumerate the revisions to be changed (with a PROPATCH to the DAV:rsr),
and then issue the CHECKIN.
Hopefully Chris will be available today to discuss this proposal.
And then just in case we have more time:
- Repositories
This is the resource type that contains a set of versioned-resources,
activities, and configurations. I have proposed that we represent the
resources in the repository as property-collections of the repository.
This I'm sure will be an interesting topic.
Cheers,
Geoff