Next message: Clemm, Geoff: "RE: Collection Fetch/Save proposal"
Date: Thu, 16 Mar 2000 17:46:14 -0500 (EST)
Message-Id: <200003162246.RAA04145@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: workspaces and configurations
From: jamsden@us.ibm.com
So is a Workspace a checked out Configuration? Its possible, but feels
like a bit of a stretch.
No, the proposal is that a configuration is just a workspace that happens
to select only revisions and no working resources. (Or alternatively,
a configuration is now able to select working resources, so now a
workspace is just a configuration).
These are very different roles to be modeled
as different states of the same object.
I suppose my response here is "no they aren't" (:-).
The behavior that really
stands out is the selection of members. A configuration is a set of
revisions that have been explicitly selected and added to the
configuration.
This current proposal is that workspaces be just that as well
(except that you can explicitly add working resources as well,
with the CHECKOUT method).
There is no rule that could ever be out-of-sync with
what's in the configuration.
There could be if we just gave a configuration an RSR property
(so that someone can tell what *should* be in that configuration,
even if it may not be that at the moment).
We had talked about creating a
configuration from a workspace by adding all the members currently in
the workspace and other ways to create configurations or add members
as a convenience. I guess I think it might be simpler to keep all
three concepts rather than try to bury the semantic differences in
state.
Or it might be simpler to just say a configuration and a workspace
are the same object, so you don't have to have methods to make them
look the same.
One problem I see with using static workspaces is that checked in
resources are lost.
A CHECKIN operation will cause the workspace to select the resulting
revision (unless DAV:keep-checked-out is specified). This removes
the whole problem of "how to make sure that checked in files don't
disappear from a workspace".
For example, say the Workspace has a revision
selection rule containing label beta01, and revision r1.1.1 of
index.html is labeled with beta01.
Note that in the new world, an RSR is just a dead property that
clients can use to remember what the argument to UPDATE should be.
The client updates his workspace to
catch up with changes released by other users and gets revision r1.1.1
of index.html. Now the client checks out index.html
which causes the workspace to select the new working resource instead
of whatever revision was selected before the CHECKOUT
and makes changes
to the working resource. On check in of index.html,
The new revision is selected by the workspace instead of the working resource.
there is no longer
a working resource, and the workspace is not dynamically updated to
select the latest on the activity index.html was checked out on (if
any) or using labeled with the workspace current-label.
The current-label (if we keep that concept) and the current-activity have
no effect on version selection. They just say what label and
activity annotations will automatically be given to checkouts and
checkins in that workspace. The new revision is selected because
that will be part of the definition of the CHECKIN method.
Cheers,
Geoff
From: Geoffrey Clemm
If we remove "dynamic version selection via RSR" functionality from
workspaces, then a workspace resource and a configuration resource
have identical semantics, except that a workspace can select both
revisions and working resources, while a configuration can only select
revisions.
We can simplify the protocol by just saying that we will only use the
more general construct, i.e. a resource that can select both revisions
and working resources. Currently, we call this resource "a
workspace", so the simplest change is to just say "we no longer need
configuration resources".
Alternatively, we could say "we will generalize the configuration
resource to allow it to select working resources, and then we no
longer need a workspace resource."
Semantically, these two choices are identical, with the only
difference being terminological, i.e. do we keep the terminology the
same and just recognize that the configuration concept is now
redundant, or do we change our terminology and use the term
"configuration" for what we used to call a "workspace".
If I *had* to pick, I'd probably just keep calling it a workspace, and
drop the term configuration (for continuity, and because
"configuration" is probably a somewhat more obscure and technical
term). But I'm happy to go either way, so if anyone has a strong
preference, please let me know.
Whether we call it a "workspace" or a "configuration", it should be a
versionable (but not necessarily versioned) resource, and I suggest
that we continue to use the term "baseline" for a "checked-in
workspace/configuration".
Cheers,
Geoff