Re: nested configurations
Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Mon, 5 Apr 1999 23:48:01 -0400
Date: Mon, 5 Apr 1999 23:48:01 -0400
Message-Id: <9904060348.AA27496@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: sv@crystaliz.com
Cc: ietf-dav-versioning@w3.org
In-Reply-To: <025c01be7fcd$3c9e8ec0$e6ea7392@honeybee> (sv@crystaliz.com)
Subject: Re: nested configurations
From: "Sankar Virdhagriswaran" <sv@crystaliz.com>
Could you folks summarize the result of the discussion (and the tele
conference) on configurations and snapshots to the versioning mailing list
and conduct all your discussions here.
First we tried to identify some common ground. The first area of
commonality was the existence of a "snapshot" or "create-revision-map"
or "checkin-configuration" operation (terminology was *not* an area
of common ground :-).
In order to describe this operation, we needed to distinguish two
kinds of URL's: a "user-URL" which is the kind of URL a user would
remember and use to locate a resource, and a "revision-URL" which is a
URL that reliably identifies a particular revision of a particular
versioned-resource.
A workspace defines a mutable mapping from user-URL's to revision-URL's
by means of its "revision-selection-rule" property.
A "configuration revision" or "snapshot" or "revision-map" defines an
immutable mapping from user-URL's to revision-URL's (I'll use the term
"snapshot" from now on, but there is no consensus on the use of that
term). So two of the ways a snapshot is different from a workspace
is: first, it cannot select working-resources, and second, it is an
immutable mapping.
One possibly illuminating analogy is:
a working-resource is to a revision
as:
a workspace is to a snapshot
Another difference between a workspace and a snapshot is that a
snapshot might only want to contain a *subset* of the mappings defined
by a workspace. The description of how to define this subset was
the next topic of discussion. Here we actually reached agreement
on the semantics surprisingly quickly, although we did end up with
three proposals for terminology.
The semantics were just that you identify a set of user-URL's. Some
suggestions for the names of this property were: "members", "roots",
and "scope" of the snapshot (I'll use the term "scope", but there
was no consensus on the use of that term).
There was general agreement that if a user-URL identified a
collection revision in the workspace, then a mapping from all
the members of that collection to the revision selected by
the workspace would also appear in the snapshot mapping.
There was a discussion about whether all the members of that
collection must appear explicitly in the DAV:scope property, but our
conclusion (and I believe there was consensus here) was that that
would lead to unacceptably and unneccessarily large and burdensome
DAV:scope property values. So the presence of a URL in the
DAV:scope that identifies a collection revision would
imply the creation of all the member mappings.
There also was a discussion about whether it is an error for
the scope to contain a user-URL for which there was no mapping
in the workspace. The conclusion was that although it might
be reasonable for us to define some mechanism by which a server
could warn a client of this occurrence, that in order to have
stability in the DAV:scope property over time, it would be better
to *not* make it an error.
Next there was a brief discussion about whether all the parent
collections of a user-URL needed a mapping in a snapshot.
Jim Whitehead volunteered to post a message about this issue
to the mailing list (which I notice he has already done), and
Jim Amsden has already responded with an explanation of why these parent
mappings are thought to be needed.
The final topic (and one that remains open) is the question of
whether the *only* way to create a snapshot is by snapshotting
the current state of a workspace, or whether you can create a
"mutable" snapshot, and explicitly change the revisions that it
selects.
One viewpoint was that explicitly adding and deleting revisions
from a snapshot would cause inconsistencies between the DAV:scope
of the snapshot and the revision mappings of the snapshot.
A response to this concern was that this could be avoided by
only allowing *changing* the revision mappings of leaf
(i.e. non-collection) URL's.
A counter to this response was that this now becomes a fairly
constrained process, while revision selection rules already
provide a completely general and extensible mechanism for
specifying exactly the revisions you want in a snapshot
(in particular, a label rule lets you pick an arbitrary set
of revisions).
The final response in this thread was that it might be more efficient
or more secure to just mutate a snapshot directly, rather than
indirectly through revision selection rules. At this point, we agreed
to continue the discussion on the mailing list.
Those who felt they needed direct manipulation of the snapshot
mapping agreed to produce some use cases or scenarios where
they felt this would be needed. Those who felt that snapshots
of the workspace suffice would then respond by how this could
be efficiently/securely handled via workspaces and revision selection
rules.
I am slightly lost on where things are. I find Chris Kaler's point about no
support for sub configurations disturbing
Jim Amsden has responded to this in a recent posting. Please post any
concerns you still have in this area (note: we didn't get a chance to
get into this much during the TeleConf, so we need a posting from
Chris to explain his concerns here).
and Jeff McAffer's points quite
interesting and could not find in the list of forwarded messages a response.
I'll be posting one, hopefully later tonight.
Cheers,
Geoff