How to create configurations
jamsden@us.ibm.com
Mon, 5 Apr 1999 10:49:23 -0400
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <8525674A.0055C37A.00@d54mta03.raleigh.ibm.com>
Date: Mon, 5 Apr 1999 10:49:23 -0400
Subject: How to create configurations
Geoff and I had a discussion last Friday on how configurations are created
and used. The issue I had with snapshots only is that they would select too
much. I wanted a configuration to contain revisions of the resources I
wanted to reuse, and not everything I could see from my current workspace.
Geoff wanted to be sure the URL namespace in a workspace was consistent and
complete when configurations were used as revision selectors. He also
wanted to ensure servers could implement efficient workspace revision
selection mechanisms. Here's what we came up with. There are some remaining
issues that we have answers for, but they're not necessarily ideal.
Resolution
A workspace is used to map simple, human readable URLs to specific
revisions of versioned resources. The selected resource is determined by
the revision selectors in the workspace revision selection rule. The
revision a workspace selects can change from moment to moment. This can
happen as the result of checking out a revision, moving a label from one
revision to another, or changing the revision selection rule.
Unlike a workspace, a configuration represents a fixed set of revisions.
The configuration members establish what revisions are in the
configuration, and these members cannot change without a user explicitly
adding or removing members. Therefore a configuration can be used to
capture a consistent set of revisions that can be reconstructed at some
future point in time. A configuration can be used as a revision selector in
a workspace revision selection rule in order for the workspace to select
revisions in that configuration.
Like a workspace, the members of a configuration consist of a mapping
between human meaningful resource URLs, and server generated revision
GUIDs. The difference is a workspace calculates the revision mapping while
the mapping in a configuration is fixed.
A configuration is a versionable resource whose members specify the mapping
between URLs and revision GUIDs. A configuration can be created and members
can be added and/or removed. Adding a resource to a configuration adds the
URL of the resource and its parent collections recursively up the
collection hierarchy to the root. The URL must refer to a versioned
resource, and the revisions selecded for the configuration must be
immutable. Adding a collection to a configuration also recursively adds the
URLs of its members. This ensures the namespace for any resource added to a
configuration is also added to the configuration so that when the
configuration is used as a revision selector in a workspace, the resource
namespace can be resolved as it was when the member was added to the
configuration.
A configuration can also be created by taking a snapshot of a workspace.
This effectively puts all the immutable revisions selected by the workspace
into the configuration. The reason for providing the ability to add and
remove members from a configuration working resource is that a workspace
shapshot may often select too many resources. This is because a workspace
will often provide a broader view of resources in order to support browsing
and development.
Issue 1: when is the mapping done between the URL and the revision GUID? If
its done when the URL is put in the configuration, then the revision
selected by the workspace might change and the configuration would have
(potentially) the wrong one. If its done when the configuration is checked
in, then checkin semantics for configurations are significantly different
than checking other resources, and the member URLs may no longer be visible
in the workspace. Another option is to add a method to configuration that
tells it when refresh its map to select the revisions currently visible in
the workspace.
Issue 2: can a configuration be used as a revision selector in a workspace
if it is not a revision? If the configuration is an unversioned resource,
or a working resource, its members could change. If the configuration is in
the workspace revision selection rule, this would cause the revisions
selected by the workspace to change. Although this is conceptually no
different than allowing the revision selection rule to be changed, there
are significant performance implications. Servers will likely cache the
mappings between URLs and revision GUIDs in order to improve revision
selection performance. This cache can be flushed when the revision
selection rule is updated, but it would be impractical to flush it every
time a configuration changed. Requiring the configuration to be an
immutable revision eliminates this problem. Another solution would be to
not make the restriction, and leave the result server defined. Servers that
dynamically calculate selected revisions in the workspace could show the
updated revision while servers that cache would show the old revision until
the RSR is updated. This doesn't result in interoperability though.
Issue 3: When adding a resource, not all the parent collections are
required to be in the configuration, only the ones used in relative URLs
for the revision. Is there any way we could specify where to stop? We
shouldn't do this as the relative URLs could always go all the way up to
the root in any document that might refer to a resource in a configuration.
There is no way for servers to know how a member URL might be used, so
there is no way to predict where to stop.