Next message: by way of : "Re: WebDAV Versioning Scenarios"
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <852568AE.0015A7B4.00@d54mta03.raleigh.ibm.com>
Date: Sat, 25 Mar 2000 21:42:34 -0500
Subject: WebDAV Versioning Scenarios
Thanks again Tim for an extremely valuable piece of work. Here's my review
of version 00.1 with additional comments based on our new model for
workspaces.
Just to summarize, I think there is a real simple way to describe the new
workspace semantics that is fully consistent and conpatible with existing
semantics. It goes something like this:
A workspace describes dynamic or variable a set of revisions. It represents
a place where a client or group of clients does work by making changes to
resources directed at some desired end result. A workspace has a revision
selection rule that describes the revisions that were selected by the
workspace creator. A workspace MAY dynamically update its contents based on
changes in the revision selection rule, or changes to resources managed by
the server, e.g., creation of new versioned resources, labeling revisions,
checking in working resources in an activity, updating a configuration,
etc. However, a server is not required to support dynamic revision
selection. Clients can use the REFRESH method to update the contents of a
workspace at any time. On REFRESH, the contents of the workspace is
refreshed with revisions as specified by the revision selection rule,
except for existing working resources. When a workspace is first created,
it MAY be empty. The first REFRESH populates the workspace with selected
revisions. On servers that do not support dynamic revision selection, the
revision selection rule only documents the revisions that were selected on
the last refresh, and cannot be relied upon to accurately reflect the exact
revisions that are contained in the workspace. Another refresh may be
required to update the revisions selected by the workspace.
So we need to make some minor changes to the existing scenarios, and add a
few new ones. First, the updates to the existing scenarios, and some
questions.
- 2.4.2: I think a server has a default workspace, not a revision. Having a
default workspace per revision is just too complicated to administer and
predict.
- So you're proposing that the workspace as a "checkout token" has to be
created and used by the client, not automatically created and by the server
and returned to the client? I agree with this approach. It's a little more
work up front for the client, but it provids a way for the client to
specify a context in which subsequent work is done.
- 2.4.3, first paragraph: ... request instructs the server uses the default
-> to use the default...
- 2.4.4 Shouldn't there be a Workspace header for specifying the workspace?
Then the Target-Selector header can be used to override the revision
selected by (or currently in) the workspace.
- 2.4.4 The response has the same content as the header. What's it for?
- Why DAV:workspace-resourcetype instead of just DAV:workspace like
DAV:collection? <D:resourcetype>D:workspace-resourcetype</D:resourcetype>
seems pretty redundant.
- 3.2.4 Target-Selector is playing two roles: specify the revision to
checkout, and specify the workspace to identify the working resource. These
roles should be split into two headers, a Workspace header and a
Target-Selector header. There are times when the client wants to checkout a
different revision than the one currently in their workspace. For example,
if the server doesn't support dynamic revision selection, and the user
wants to be sure to checkout the right revision. In any case, the overview
should enumerate both roles.
- 3.4, 3.5 can delete these sections because of new workspace semantics.
There is no need for workspace current-label or current-activity. Revisions
can't disappear from a workspace on checkin. Current-activity can now be a
parameter of checkout, checkin, or both.
- 4.5 Update to show static and dynamic revision selection.
- 4.5.3 Add a note that the workspace MAY not contain the revisions
indicated by the revision selection rule until a refresh is done.
- 5.2 Note that I do not thing a configuration is a checked in workspace. I
think there are may reasons to keep these concepts separate. One might be
derived from the other, or have a common parent (a collection), but they're
not the same thing.
- 5.5 Indicate the workspace may need to be refreshed first.
- 7. Delete this section. I think baselines are unnecessary additional
complexity and their behavior is covered by configurations.
New scenarios needed:
- Create a new basic workspace without a revision selection rule. In this
case, the workspace only acts as a selector for working resources. It plays
no other role.
- Create a new workspace with a revision selection rule, on a server with
NO dynamic revision selection. The workspace contains no revisons. Is
really the same as a basic workspace in that it can be used to select
checked out working resources.
- Refresh a workspace to populate it with the revisions selected by the
revision selection rule.
- Make changes to resouces that would result in a different revision being
selected by a workspace. e.g., move a label that's in the workspace
revision selection rule.
- Show that the workspace contains a different revision than the newly
labeled revision.
- Refresh the workspace.
- Show that the workspace now contains the newly labeled revision.
- Same scenarios with a server that does support dynamic revision
selection. Show that the workspace contains the newly labeled revision
after the LABEL operation, and the Refresh is a no-op.
- Checkout makes the revision in the workspace an editable working resource
in that workspace.
- Checkin creates a new (potentially) immutable revision, but leaves the
revision in the workspace. No need for current label or current activity
for this to work.
- Merge a workspace into another workspace generating a conflict report
using the MERGE method. Show how the merge method on revisions resolves the
conflict.
- Designate one workspace as the "team", or "integration" workspace.
Designate another workspace as a user's "working area". Show how the user's
workspace can catch up with the team by merging the team workspace into
their workspace. Show how the user can release their changes to the team by
merging their workspace into the team workspace.
- Show how a server can support many team or integration workspace, and
many user working area workspaces.
- Need down-level clinet scenarios that use the default workspace and auto
versioning.
- Create a configuration from a workspace by selecting the revisions
currently in the workspace. May want to do a refresh or merge on the
workspace first to be sure it has the expected revisions. (This might be
the only way to create a configuration. We have to think about this).