Re: nested configurations
jamsden@us.ibm.com
Wed, 7 Apr 1999 09:44:37 -0400
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <8525674C.004B963B.00@d54mta03.raleigh.ibm.com>
Date: Wed, 7 Apr 1999 09:44:37 -0400
Subject: Re: nested configurations
Geoff,
I agree with most of this, with the following notes and/or exceptions:
Can we use snapshot as the operation that binds member URLs in a
configuration to the revisions selected by the current workspace?
Can we stick with defining a configuration as an immutable map from user
URLs to revision URLs? I don't see a need to define a new term for this.
Jumping from term to term seems to be making it difficult to understand the
semantics.
Identifying a set of user-URLs for a configuration is *exactly* what a
collection does. So I continue to believe a configuration is a
specialization of a collection with the additional semantics of mapping its
members to specific revisions of versioned resources. Like collections,
adding a member has implications about its parents and children that we can
define. So I vote for sticking with member to denote the things a
configuration contains. We can talk about the binding of the member for the
role the other URL plays as new configuration behavior. Or the member might
be a reference if we just use references to establish both membership in
the configuration and the mapping. Recall that the model currently says
configurations are a kind of collection whose members are direct references
to immutable revisions of versioned resources. Does this provide the
functionality and semantics we need introducing the minimum number of new
concepts and terms?
I believe it is an error for a configuration to contain a member that has
no selected revision in the current workspace *when* the configuration
snapshot method is invoked. It might not have a mapping at any other time,
but that's OK. The effect of the error may not be to remove the member
though, so we get the flexibility you want and the notification I think
users will expect. Otherwise we run the risk of putting a URL in a
configuration expecting to get some revision when we use the configuration
in an RSR at some future time. The best case is that you'll get resource
not found when you attempt to access this URL using the configuration. The
worse case is that the workspace might select some other, inconsistent
revision because of some other revision selector in the RSR without you
knowing it. This is not in the spirit of how configurations are used and
feels a little like mutable configurations as the revision selected might
change even though the configuration has the URL as a member.
As far as editing the configuration is concerned, I am most interested in
being able to support resource reuse by specifying the members of the
configuration and getting them mapped to a revision somehow. This is a
complex process because of collection namespaces. I'm happy with adding
and/or removing members, and doing a configuration snapshot to establish
the links from revisions selected by a workspace. It may be possible to
provide more flexibility by allowing members to be bound specifically when
they are added to the configuration, or by allowing members to be
individually re-bound to some other revision. These are nice-to-haves
and/or server optimizations, but don't seem absolutely necessary. Perhaps
we could do the minimum for now and explore more flexible options when we
have some more implementation experience.
"Geoffrey M. Clemm" <gclemm@tantalum.atria.com> on 04/05/99 11:48:01 PM
To: sv@crystaliz.com
cc: ietf-dav-versioning@w3.org (bcc: Jim Amsden/Raleigh/IBM)
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