Washington IETF Delta-V Meeting Notes
jamsden@us.ibm.com
Mon, 29 Nov 1999 19:15:56 -0500
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <85256839.00018BDC.00@d54mta03.raleigh.ibm.com>
Date: Mon, 29 Nov 1999 19:15:56 -0500
Subject: Washington IETF Delta-V Meeting Notes
The Delta-V Working Group held its first meeting November 9, 1999 at the
Washington, DC IETF. The meeting covered the proposed extensions to WebDAV
to support versioning, activities and parallel development, and
configuration management. The following are the notes from the meeting.
Chair: Jim Amsden
Notetakers: Jim Whitehead, Pete Carlson
Meeting begins with a review by Jim Amsden of the meeting agenda, including
some scoping of the desired discussion for today's session. The approach
taken was to walk through the protocol by showing how the scenarios from
the goals document would be communicated to a WebDAV versioning server. The
purpose was to review the goals and semantics through the scenarios, sketch
how the scenarios are supported by the protocol, and raise any issues. We
intentionally did not cover
- clients that maintain their own workspace
- local and disconnected modes (master mode only)
- dynamic resources
- locking pending resolution of locking semantics on unversioned resources
- leveling or optional features. This will come later after we have a
complete understanding of the full versioning semantics.
First item is a versioning scenario. (The notes from the overheads are
included below). In the scenario, want to:
- create a resource
- update it
- make it a versioned resource
- track its history while making some revisions
Geoff Clemm then presented how the protocol would address this scenario:
- create a resource
PUT /a/x.html
"some text"
PUT /a/x.html
"some more text"
{Creates the resource, then updates it once, but it currently isn't under
version control.}
At this point in time, there is:
resource: /a/x.html
creation date: 11/9/1999 1:25PM
"some more text"
VERSION /a/x.html
This puts the resource under version control
PROPFIND /a/x.html
resource now has a new property (versioned-resource):
resource: /a/x.html
creation date: 11/9/1999 1:25PM
versioned-resource: {some URL "zz157"} <-- the URL where you can
retrieve the entire versioned resource
"some more text"
Need to create a workspace to isolate your changes from those of other
collaborators.
MKRESOURCE /workspaces/geoff_dev
current-label: geoff_dev_lbl
revision selection rule:
<label>geoff_dev_lbl
</label>
This creates a new workspace, where items are assigned the label
"geoff_dev_lbl" and the revision selection rule always picks out the
revision where the label is "geoff_dev_lbl".
--> /workspaces/ was previously created, and established as the place
people store their workspaces.
CHECKOUT /a/x.html
Target-selector: workspace /workspace/geoff_dev
Chris Kaler noted that this checkout will fail, because as of this point,
no label has been set on /a/x.html (wasn't done by VERSION, or by GET).
This leads to some discussion on how to resolve the problem. Two choices,
either have VERSION set a initial label, or can change the revision
selection rule. Geoff proposed to modify the revision selection rule.
Kevin Wiggen noted that the MKRESOURCE didn't specify that it's creating a
workspace resource. So, MKRESOURCE now looks like:
MKRESOURCE /workspaces/geoff_dev
resource-type: workspace
current-label: geoff_dev_lbl
revision selection rule:
<label>geoff_dev_lbl
</label>
<latest/> <or/>
What does "zz157" (the URL of the versioned resource) look like?
/zz157:
resource-type: versioned-resource
revisions: /zz157/revisions
Issue: what is inside the "revisions" tag. Is it a collection, or a
report? This has not yet been resolved. (Note: this issue was discussed
and resolved in the breakout session the following day. See the meeting
notes for details.)
Working on the assumption it is a collection:
/zz157/revisions
Further assuming the server names its revisions as "r{version id}", then
the versioned resource now has:
/zz157/revisions/r1 <-- this is the stable, reliable name of the
revision. A GET on this returns revision 1 of /a/x.html
There is also a collection for labeled revisions:
/zz157/labeled_revisions/
At present, since no label has been assigned, this is empty. Return back
to editing.
So, do a PUT to write into the currently checked-out working resource at
/a/x.html. The working resource is part of the workspace, that is, it
lives in /workspaces/geoff_dev/...
PUT /a/x.html
"final text"
Target-selector: workspace /workspace/geoff_dev
Then, check it in:
CHECKIN /a/x.html
Target-selector: workspace /workspace/geoff_dev
The act of checking in the resource sets the label on that revision
(revision 2). Going back to zz157, there are now the following resources
in /zz157/revisions:
/zz157/revisions/r1
"some more text"
/zz157/revisions/r2
"final text"
Also, in /zz157/labeled_revisions/, there is:
/zz157/labeled_revisions/geoff_dev_lbl
This is the same resource as /zz157/revisions/r2.
A question was raised about the use of labels. Are they used to track each
user? Chris Kaler: no, it's more tracking a line of work. Q: So, your
exploiting a side effect of labels here. GC: yes.
Some back and forth on how labels are used, and their role, especially in
keeping clients separate.
Question about what a label really is. Geoff answered by giving details on
exactly how the label is expressed:
labels: <label>geoff_dev</label>
<label>stable</label>
Geoff emphasized that you can have multiple labels set on a resource. More
discussion on uses of labels. Labels are not particularly good for audits.
Q: Can the same label be used across multiple resources? A: yes,
definitely.
This ends the first scenario. Now, move on to a scenario involving
parallel development. Build on the end state of the first scenario:
User Jim checks out a revision of /a/x.html with label geoff_dev_lbl
User Geoff checks out a revision of /a/x.html with label geoff_dev_lbl
Need a new workspace for Jim:
MKRESOURCE /workspaces/jim_dev
resource-type: workspace
current-label: jim_dev_lbl
revision-selection-rule: <label>jim_dev_lbl</label>
<label>geoff_dev_lbl</label>
<or/>
<latest/> </or>
CHECKOUT /a/x.html
Target-selector: workspace /workspaces/jim_dev
But, immediately after this, the server sees:
CHECKOUT /a/x.html
Target-selector: workspace /workspaces/geoff_dev
After both checkouts, /zz157/revisions/r2 looks like:
/zz157/revisions/r2
"final text"
labels <label>geoff_dev_lbl</label>
<label>stable</label>
workspaces: /workspaces/jim_dev/
/workspaces/geoff_dev/
As each person checks in, the items in workspaces go away, and revisions
are added to the successors list:
successors: /zz157/revisions/r3
/zz157/revisions/r4
Now, we want to:
- retrieve the history listing (list predecessors and successors)
- add/remove labels
At present, to make a history listing, need to go to the versioned resource
and retrieve the URL of its revision collection, and then do a PROPFIND
with Depth to retrieve the predecessor and successor relationships off each
individual resource. Could potentially have an optimization to PROPFIND to
handle the first two retrievals. Also have the option to do a REPORT
method invocation (handles actions that require a lot of computation on the
server), with one report being a history listing. Could also have a
property on the versioned resource that contains the history listing.
Setting a label:
One option is to go into the labeled revisions collection:
/zz157/labeled-revisions/
to add a label called "default":
BIND /zz157/revision/r2
Destination: /zz157/labeled-revisions/default
to change it:
BIND /zz157/revision/r4
Destination: /zz157/labeled-revisions/default
Alternately, could use a "LABEL" method:
LABEL /a/x.html
Label-name: default
Lisa Lippert: For simple clients, needing to understand BIND functionality
may be too much, and labels may be too complex.
GC: Could be quite simple, a client could just think of the BIND as a
"recipe" that they just execute.
LL: If it's so simple, why can't they just do a PROPPATCH?
GC: Could use PROPPATCH {explained a scenario of how to do this}. One
drawback of this approach is if there are a large number of labels on a
revision, then doing a PROPFIND to retrieve this large set of properties,
followed by a PROPPATCH after making a minor modification, could be
inefficient.
JH: Every time you have a list of items that needs to be changed, you run
into the lost update problem where a modification could be made between
PROPFIND and PROPPATCH.
A (many): Yes, this is the case.
Lisa Lippert: Multi-valued properties, in many cases, would be useful if
you could add or remove elements from the list. This will be very useful
in ACLs, since it'll be useful to add/remove access items, especially if
you can't read the items. I'd be happy to work with other people on this.
GC: I'd like to see this too, I certainly like this much better than having
a separate method to add/remove list items for each type of list.
Jim W: Is the BIND side-effect to create a label the only reason why labels
are exposed through the namespace?
GC: No, the main reason is to have a stable URL for "label X of revision R"
to avoid having to create a (revision, label) pair syntax.
Jim Amsden: To finish up, let's request from the WG members their
perceptions of the protocol.
Lisa Lippert: I'm concerned about the complexity of the protocol for simple
authoring clients. Checkin/checkout, and retrieving a history list have to
be really simple.
Yaron Goland: Need to have a document that explains choices, paths not
taken, etc. Design rationale.
GC: Agreed -- weren't you going to write this?
Q: Need to list required metadata fields in the specification.
*** Meeting Adjourned ***
Scenario1:
- create a resource
- update it
- make it a versioned resource
- make some revisions
PUT /a/x.html
"some text"
PUT /a/x.html
"some more text"
VERSION /a/x.html
GET /a/x.html
=>
"some more text"
MKRESOURCE /workspaces/geoff_dev
resource_type: workspace-resource-type
current-label: geoff_dev_lbl
revision-selection-rule:
<or> <label> geoff_dev_lbl </label>
<rsr-latest/>
</or>
CHECKOUT /a/x.html
Target-Selector workspace /workspaces/geoff_dev
PUT /a/x.html
Target-Selector workspace /workspaces/geoff_dev
"final text"
CHECKIN /a/x.html
Target-Selector workspace /workspaces/geoff_dev
Scenario 2:
Jim checks out and updates /a/x.html
Geoff checks out and updates /a/x.html
Geoff checks in /a/x.html
Jim checks in /a/x.html
MKRESOURCE /workspaces/jim_dev
resource_type: workspace-resource-type
current-label: jim_dev_lbl
revision-selection-rule:
<or> <label> jim_dev_lbl </label>
<rsr-latest/>
</or>
CHECKOUT /a/x.html
Target-Selector workspace /workspaces/jim_dev
PUT /a/x.html
Target-Selector workspace /workspaces/jim_dev
"Jim's text"
CHECKOUT /a/x.html
Target-Selector workspace /workspaces/geoff_dev
PUT /a/x.html
Target-Selector workspace /workspaces/geoff_dev
"Jim's text"
CHECKIN /a/x.html
Target-Selector workspace /workspaces/geoff_dev
CHECKIN /a/x.html
Target-Selector workspace /workspaces/jim_dev
Scenario 3:
List revisions of /a/x.html
List labeled revisions for /a/x.html
Label revision r1 as "default"
Look at revision r1
PROPFIND /a/x.html
versioned-resource
=>
versioned-resource: /zz157
PROPFIND /zz157
revisions
labeled-revions
=>
revisions: /zz157/revisions
labeled-revisions: /zz157/labeled-revisions
PROPFIND /zz157/revisions
Depth: Infinity
=>
<href> /zz157/revisions/r1 </href>
<href> /zz157/revisions/r2 </href>
<href> /zz157/revisions/r3 </href>
PROPFIND /zz157/labeled-revisions
Depth: Infinity
=>
<href> /zz157/revisions/geoff_dev_lbl </href>
<href> /zz157/revisions/jim_dev_lbl </href>
BIND /zz157/revisions/r1
Destination /zz157/labeled-revisions/default
GET /zz157/revisions/r1
=>
"final text"
PROPFIND /zz157/revisions/r1
labels
successors
=>
<labels> <label> default </default> </labels>
<successors> <href> /zz157/revisions/r2 </href>
<href> /zz157/revisions/r3 </href> </successors>