FW: Configurations
Jim Whitehead (ejw@ics.uci.edu)
Fri, 2 Apr 1999 11:28:32 -0800
From: Jim Whitehead <ejw@ics.uci.edu>
To: Versioning <ietf-dav-versioning@w3.org>
Date: Fri, 2 Apr 1999 11:28:32 -0800
Message-ID: <000f01be7d3e$fec329c0$d115c380@ics.uci.edu>
Subject: FW: Configurations
-----Original Message-----
From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com]
Sent: Thursday, April 01, 1999 12:20 PM
To: jamsden@us.ibm.com; gclemm@atria.com; ejw@ics.uci.edu;
dgd@cs.bu.edu; Cragun.Bruce@gw.novell.com;
sridhar.iyengar@mv.unisys.com; ckaler@microsoft.com;
bradley_sergeant@intersolv.com; ABabich@filenet.com;
Jeff_McAffer@oti.com
Subject: Configurations
Don't know if I sent this out or not. Sorry if its a duplicate.
"Geoffrey M. Clemm" <gclemm@tantalum.atria.com> on 04/01/99 12:31:15 AM
To: Jim Amsden/Raleigh/IBM
cc: Jim Amsden/Raleigh/IBM, ejw@ics.uci.edu, dgd@cs.bu.edu,
Cragun.Bruce@gw.novell.com, ckaler@microsoft.com,
bradley_sergeant@intersolv.com, Jeff_McAffer@oti.com
Subject: Re: configurations and snapshots
Just to make sure we separate semantics from terminology:
<jra>
terminology is how we describe our semantics. Let's separate semantics from
protocol from implementation.
</jra>
There is an immutable object that captures a set of revisions, and is
suitable for placing in a revision selection rule. This is the most
important object, and needs a name of its own.
<jra>
This *is* a configuration, and it doesn't have to be immutable. It can be
unversioned, or be a mutable revision. It's just its members that can't be
mutable. The point is nothing changes in a configuration unless you add or
remove a member.
</jra>
There are frequently a series of these immutable objects that are
created, that are connected by a logical predessor/successor relation.
In addition, there are cases where several such immutable objects are
"merged" into a single new immutable object. This means that this
series of immutable objects looks very much like a special kind of
versioned resource.
<jra>
No. A configuration is a versionable resource just like most other
resources. It has its own DAV:contenttype, probably DAV:configuration, and
is just like any other resource. There is no reason to require a
configuration itself to be immutable, never unversioned, or never a working
resource. This would create some kind of new object that would have very
odd semantics. Something you can create, but its always a revsion, but you
can't check it out and change it, you can only create a new revision with a
special operation. I don't like this at all. I hope implementations aren't
forcing this semantic because I am working on an implementation using the
file system that doesn't have these constraints.
</jra>
Originally, we were using the term "configuration" for the first object,
and had no name for the second object, other than "a versioned resource
whose revisions are configurations".
<jra>
What's the matter with that! "There are frequently a series of these
immutable objects that are created, that are connected by a logical...". It
doesn't sound like you are talking about two different objects, but rather
the life-cycle of a versioned object. Why do you want to special-case
configurations. This seems entirely unnecessary to me from both a logical
and implementation standpoint.
</jra>
We (or at least, some of us :-) then switched to calling the *second*
object a configuration, and the first object a "configuration revision".
This gave us a usable name for both objects. But the most important
object now had a two-word, eight-syllable name, so we decided to give
it a new name, "snapshot". So now we can say "a snapshot is a
configuration revision".
<jra>
So "XML document revision", "GIF revision", "<you-name-it> document
revision" aren't useable names? Certainly we don't want to invent
convenient names for all the potential roles these revisions might play on
the web. Why are configurations so different?
</jra>
So my conclusion from all this is that we need good names for each of
these two objects, but I'm not attached to either one of the current
names.
<jra>
I have absolutely no problem calling a snapshot a configuration created by
doing a snapshot of a workspace. I don't see any reason why this has to be
an immutable revision unless that's what a user wants though. For example,
one might use a snapshot to create a configuration just to make it easier
to give someone something they can reuse to see the same revisions someone
else is using without reusing the same workspace. John snapshots his
workspace and gives it to Jane. Jane puts the temporary, unversioned
configuration in her workspace revision selection rule so she can see
John's revisions. This is just a convenience. She could have taken a copy
of John's RSR and merged it with hers to get the same effect. If Jane wants
to keep the configuration for some reason, and ensure it doesn't change,
she can check it in and create a versioned configuration.
</jra>
Then a protocol question is:
- Do you create a new snapshot with a "MKSNAPSHOT" method, or a pair of
CHECKOUT/CHECKIN methods on an existing snapshot.
<jra>
Both. MKSNAPSHOT takes a workspace as the resource target and a header
containing a URL that on successful completion of the method will contain a
configuration whose members are the immutable revisions selected by that
workspace. If you want to version the configuration, then check it in.
Otherwise don't. If you want to change a configuration, check it out (if
its a revision), and either re-snapshot, or add and/or remove revisions and
check it back in.
</jra>
And some *semantic* questions are:
- Can you create a snapshot that is not part of a configuration?
(if so, you must have MKSNAPSHOT)
<jra>
Some systems have the notion of taking a snapshot of a workspace so you can
get back to that state of the workspace, including checkouts, working
resources, RSR, activities, etc. I don't think we should do this.
</jra>
- Can you modify a checked-out snapshot, or can you only check it in?
(only relevant if you use CHECKOUT/CHECKIN to create new snapshots)
<jra>
Definitely.
</jra>
Cheers,
Geoff