Next message: Tim Ellison/OTT/OTI: "MKRESOURCE response"
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <852568A4.0052E907.00@d54mta03.raleigh.ibm.com>
Date: Thu, 16 Mar 2000 10:05:32 -0500
Subject: Re: workspaces and configurations
Geoff,
This sounds good, but may be taking the simplification a little too far.
Certainly the behavior of an object is state dependent, and it is often
hard to determine if one is talking about an object in a different state or
a different object. Let's explore the behavior of a workspace,
configuration, and baseline as we currently understand them to see if they
are different objects or the same object in different states.
Workspace
- represents a place to do work separated from other users/roles doing
concurrent work on potentially the same resources
- is used to access working resources
- revision selection is based on a revision selection rule (I suggest we
keep this concept even if the workspace is refreshed/updated manually. This
is so the client can have an idea what was used to select the revisions on
the last update, and enables dynamic workspace update by servers that want
to support it).
- revision selection could be either/both dynamic or static driven by a
Workspace.update() method
Configuration
- represents a static set of selected revisions that are related in some
way
- cannot contain/reference/select working resources or unversioned
resources
- revision selection (i.e., membership in the configuration) is through
explicit add/remove on a checked out configuration
- revision selection is never dynamic
Baseline
- As far as I can see, a specialization of a configuration associated with
a collection that contains a revision of that collection and recursively a
revision of all its members
- is created as a special method on a collection revision (effectively)
So is a Workspace a checked out Configuration? Its possible, but feels like
a bit of a stretch. These are very different roles to be modeled as
different states of the same object. 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. There is no rule
that could ever be out-of-sync with what's in the configuration. 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.
One problem I see with using static workspaces is that checked in resources
are lost. 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. 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 and makes changes to the working resource. On check
in of index.html, 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. Systems that copy resources into a workspace don't have this
problem because the copy is often retained (and made read-only) after
checkin.
|------------------------+------------------------>
| | "Geoffrey M. Clemm" |
| | <geoffrey.clemm@ratio|
| | nal.com> |
| | Sent by: |
| | ietf-dav-versioning-r|
| | equest@w3.org |
| | |
| | 03/16/2000 09:22 AM |
| | |
|------------------------+------------------------>
>------------------------|
| |
| To: |
| ietf-dav-versioning@w|
| 3.org |
| cc: |
| Subject: |
| Re: workspaces and |
| configurations |
>------------------------|
Upon re-reading my post, it occurs to me that I may have made this
a bit more obscure than it had to be. So I'll try a revised version:
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
Date: Thu, 16 Mar 2000 08:09:00 -0500 (EST)
From: "Geoffrey M. Clemm" <geoffrey.clemm@Rational.Com>
One point I neglected to add to the minutes from this week's conference
call was Henry's suggestion that if we were removing the "dynamic"
behavior
from workspaces, why not unify the concept of workspaces and
configurations?
After some reflection, it appears to me that it makes good sense to
model the new "stable" workspace object as simply a checked-out
configuration, i.e. a "working configuration". This not only unifies
the concept of workspaces and configurations, but also unifies the
notion of baselines and configurations (a baseline is the "checked in
state of a workspace", and in this simplified model, all checked-in
configurations will by definition always be the checked in state of a
workspace).
Unless there are objections, I will include this unification in the
"stable workspace" proposal I'm working up.
Cheers,
Geoff