Re: configurations and snapshots
Jim Whitehead (ejw@ics.uci.edu)
Fri, 2 Apr 1999 10:58:53 -0800
From: Jim Whitehead <ejw@ics.uci.edu>
To: Versioning <ietf-dav-versioning@w3.org>
Date: Fri, 2 Apr 1999 10:58:53 -0800
Message-ID: <000701be7d3a$da4ff180$d115c380@ics.uci.edu>
Subject: Re: configurations and snapshots
-----Original Message-----
From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
Sent: Wednesday, March 31, 1999 9:31 PM
To: jamsden@us.ibm.com
Cc: jamsden@us.ibm.com; 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:
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.
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.
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".
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".
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.
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.
And some *semantic* questions are:
- Can you create a snapshot that is not part of a configuration?
(if so, you must have MKSNAPSHOT)
- 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)
Cheers,
Geoff