Next message: Ross Wetmore: "BATCH operation [was Re: Comments on draft-ietf-deltav-versioning-08]"
Date: Mon, 25 Sep 2000 10:19:03 -0400 (EDT)
Message-Id: <200009251419.KAA24540@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: Comments on draft-ietf-deltav-versioning-08
From: Ross Wetmore <rwetmore@verticalsky.com>
"Geoffrey M. Clemm" wrote:
> You should be able to get much of the optimization you need from
> the HTTP-1.1 ability to keep a connection alive.
If conditional execution or rollback is required, then one is limited
to complete network turnaround between operations, plus the added burden
of additional checks to make sure that overlapping operations have not
modified the underlying state, or for 3rd parties, that they have not
picked up partial state for a composite operation. This is significant
overhead vs a BATCHed atomic operation and is not helped by keep-alive.
Yes, I agree (the live connection only saves you the cost of re-connecting).
Unfortunately, requiring atomic behavior for compound operations (especially
for client defined compound operations) pretty much limits the possible
implementations to database systems, and for scalable multi-user access,
a fairly sophisticated database system.
Is there the intention to have such issues be addressed in a
broader context or a supplement to this suppplement? Or is it the
collected wisdom that these are not (at least immediately, or
without further experience) issues for concern?
They are issues for concern, but no interoperable solution that is
implementable on a wide variety of repositories has been proposed.
> Which is the precise concept desired here for creator-displayname
> author or owner, (content or object) creator?
>
> It's intended to be resource (object) creator, but in the case of
> a versioning system, where each new interesting state is stored as
> a separate resource (a version), the distinction becomes fuzzy.
In this case "creator" carries the semantics of "content creator". There
is not a good match for "object owner" though "publisher" comes closest. It
appears that "creator-displayname" is actually the wrong connotation. For
the versioning history object "owner-displayname" might be better.
A problem with "owner" is that many systems tie the concept of owner
to access control, and allow you to change the owner of a resource
(whereas we want this property to represent history and therefore it should
not be changed unless it didn't accurately reflect the history).
So although "creator" is "object-creator", if you look at the object creator
of an individual version, it is a reflects the "content creator" for that
particular version.
> Section 8
[...]
The explanations here were very helpful, many thanks.
To summarize my understanding, it is possible to automatically share
updates by using a common version selector.
Yes, although as you point out below, its not quite "automatically",
since you do have to request the MERGE or SET-TARGET to update one
version selector with a version created by a different version
selector.
If two version selectors
point to the same version, then the second will only see changes from
checkin of the first after a merge is performed.
Yes (or SET-TARGET).
A working version may
be checked out through a version selector to a new Url (if the target
version was selected by 10.2 checkout <target>), or the version selector
may be checked out in-place. If checked out to a new Url, it is the
responsibility of collaborating processes to pass the Url of the working
version for any shared updates.
Yes.
If checked out to a new Url, the version
selector will be unaffected and still contain the contents and dead
properties of the original version until the working resource is checked
in (can the working resource be checked in through the version selector?
A checkin of a working resource does not automatically modify the
target of the version selector from which it was checked out. This
is optional, and if desired, must be done explicitly with a subsequent
SET-TARGET to the appropriate version selector.
Note that before we separated the concepts of a checked out version
selector and a working resource, we always had the checkin update the
version selector (because that was the only thing that made sense for
an in-place checkout), and then had a "hidden" checkin (that didn't make
sense in the context of an in-place checkout).
This is now simpler. A CHECKIN now just creates a new version, and has
no effect on the content or dead properties of the version selector.
or must the version selector be explicitly updated after working resource
checkin?).
Yes.
If a version selector is checked out in-place, it in effect
becomes the working version.
Yes, it is directly modifiable (e.g. by a PUT or PROPPATCH), but I'd
probably avoid the term "working version" since this could cause confusion
with "working resource". I'd prefer to just say that "both a checked-out
version selector and a working resource are checked-out resources".
It will have a "checked-out" property pointing
to the original target version and the original target property will be
missing. It will be automatically updated on checkin to remove the
checked-out property and restore the target now pointing to the new version.
Yes.
> Each workspace has its own set of version selectors (so they don't
> redirect through a common version selector).
This raises further questions about collaborative sharing of versioned
resources. Let me try to setup a scenario to illustrate.
If there are three teams sharing a common set of resources, one can
draw overlapping circles to represent the "workspaces" which define each
team's conceptual set of interest. In the general case there will be
resources shared by all, shared by each of the 3 pairs and 3 not-shared.
To support effective sharing, it is not the resources that are shared,
but rather the changes that are shared. For example, it is not the
case that I want to see "all changes to foo.html by team-3" or "all
changes made to bar.html by team-1 and team-4". Instead, I want to
see certain changes, e.g. "fix dangling references to copyright" from
team-1 and "add animated titles" from team-3. What resources those
changes involve are something I cannot (and should not try to) predict.
Capturing logical changes is what "activities" are all about.
Each team may have more than one workspace: headrev (for live changes),
latest build (a consistent set of resources) and qa-approved (a tested
set of consistent resources).
Sounds reasonable. Note though that in many scenarios, each team
would also have a separate "development workspace" for each member of
the team. This allows a team member to do work without being
disrupted by changes made by other members of the team.
Ideally, one would like to consider the
latest-build and qa-approved sets in each team as workspace versions or
baselines of each headrev workspace.
Yes, each "latest-build" set would best be represented as a separate
baseline, and the "qa-approved" set would then be baselines
that have a "qa-approved" property set on them.
In order for the sets of resources in these baselines to be visible
(i.e. for running the tests), they would have to be loaded into a
workspace, though.
For the moment, consider only headrev
in which all teams automatically share any new versions.
Note that if they are checking out the version selectors, they will
also automatically share any updates to the checked out version
selectors. If they are using working resources, then the new versions
will only be visible when someone performs a SET-TARGET.
How might the headrev workspaces for each of the 3 teams be setup
if version selectors cannot be shared? Does this mean that one
must setup appropriate combinations of 7 sub-workspaces?
As indicated above, I believe that it doesn't make sense to define
sharing boundaries on a resource basis, but rather on an activity basis.
If so, what does this mean
when a team decides it wants to add or drop a resource from its headrev
workspace, i.e. will it have to move from one of the sub-workspaces to
another?
When you say "add or drop a resource", I believe you mean "change which
other teams that resource is shared with". As indicated above, I don't
believe that can form an effective basis for sharing. Instead, you
will want to either "merge a whole baseline" from some team or "merge
an activity" from some team.
This is a reasonably common scenario, but I don't really see how the
current proposed standard would handle it. What have I missed?
Let me know if my responses above still need clarification (or if you
disagree with my conclusions on the merit of resource vs. change based
sharing).
> 10.6
To clarify "There is no corresponding pre-condition 'cannot move label'"
the unstated implications are:
Apart from version selection errors, a "set" command always succeeds. It
will delete any current label if present (but not require one) and apply the
new label to the indicated version.
Correspondingly, an "add" performed twice in succession is guaranteed to
produce an error on the second application, even though the new label is
that of the version to which it is applied.
Are these interpretations correct?
Yes.
Cheers,
Geoff