Next message: jamsden@us.ibm.com: "Re: Stable URLs"
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
cc: minutes@ietf.org, Patrik Fältström <paf@swip.net>, ned@innosoft.com
Message-ID: <852568BA.004B981D.00@d54mta03.raleigh.ibm.com>
Date: Fri, 7 Apr 2000 09:45:31 -0400
Subject: IETF 47 Delta-V Working Group Notes
Notes from the Delta-V working group meeting at IETF 47 in Adelaide.
Jim Amsden jamsden@us.ibm.com
Mailing List: ietf-dav-versioning@w3.org
Send a subscribe to ietf-dav-versioning-request@w3.org
2nd WG Meeting, 1st at December IETF. Has been going on a while,
"informally". Put together a charter, got WG status last year.
Approximately 20 participants present
Special thanks to Kelly Morse Johnson for taking notes!
Review of Working Group Status/Charter
Review Versioning Scenarios
* explore common use cases
* understand versioning mode/semantics
* see how the protocol supports the versioning mode
Explore Issues
* locking
* static vs. dynamic workspaces
* repository and down-level clients
* handling default revision selection
* configurations vs. baselines
-=-=-
Where we're at:
There is a charter, it has a schedule. Go look at it. We are on or
slightly ahead of that charter. Have a design team - no membership
requirements. Want to hold DT meetings between WG meetings and
during IETF. DT is smaller group of dedicated folks doing the bulk of the
work. Focus has been to make sure we are supporting entry level
capabilities. 2 sections, basic/core and advanced.
WebDAV Implementations, see:
mod_dav <www.webdav.org> (Apache module in C)
DAV4J <www.alphaworks.ibm.com> (protocol agnostic, supports backends) (a
Java servlet)
others listed at www.webdav.org
Experience so far: has been some controversy: Feb DT meeting was
interpreted as an interim meeting - misunderstanding - it was a design team
meeting that was not
intended to substitute for a WG meeting.
WebDAV trying to finish the advanced collections specs.
Versioning is dependent upon Binding.
Access Control: In WebDAV. Had a BOF at December 98, kind of a
disaster. A lot of poor communication. Left a negative feeling in a lot
of participants. Pretty much dropped until very recently. The spec that
was supposed to have been reviewed, is now being reviewed. Spec hasn't
been updated, tho. Jeff Clemm now involved. ACLS is probably going to
re-surface. JAVA2, ACLS model in Windows, SecureWay from IBM, any
commonality that WebDAV can map? Interop between servers the goal.
Lots of activity on the webdav mailing list.
*** Need to correct the examples and scenarios to correspond to the updated
versioning spec. Important to keep these in sync as protocol implementors
sometimes implement to the examples when the spec is unclear or ambiguous.
Walk through the scenarios:
Assume there's a WebDAV server with no resources on it currently. 1st
thing to do is create some resources. Then update a resource. Put the
resource under version control (WebDAV version extension). Now that it is
versioned, you can no longer PUT to it, but you must work within the
versioning framework. Check out a versioned resource to permit
updates. Once you have a versioned resource, you must specify which
revision you want to use, not just the URL.
Workspaces. Everyone wants to be able to work in an independent space with
some common team integration area. This is a workspace. It is a resource
on the web, and specify what resources and revisions of resources you want
to see. Revision can depend on your workspace.
<method> <target>
For example:
GET /foo.html
Host: a.b.com
Workspace: /workspaces/jim.wks
- or -
Revision-Selector: beta2
(specify workspace which specifies the interesting revisions, or specify a
revision label, or the server can specify a default workspace and return
the version in that WS (could be "latest" revision))
It would have been nice to have a combined URL with a revision specifier
munged together. Told by someone? that clients can munge URLs, but servers
can't.
Issues with down-level client?
Workspaces are the identifiers for a Working Resource. A token that
identifies a WR. WS really can be a very lightweight concept.
Do a PUT to save your changes, but your changes won't get put into the
repository until you actually check the resource back in (CHECKIN). Can do
many PUTs, but must use CHECKIN to create the new revision with your
changes.
Put human-meaningful labels onto a revision (LABEL). UTF8 charset.
Can use labels to get old revisions, labeled revisions, define a label for
your workspace.
Static and Dynamic workspaces:
A dynamic WS has a revision selection rule to specify a set of revision
selectors.
Dynamic WS automatically update the selection revision if it changes (label
moved, etc.)
Static WSs are just like CVS directories. (Supports "team stream" model)
Dynamic WSs is like Clearcase.
Can use merge or compare - will actually do the merge, or just tell you
what has changed, been added, or removed.
*** WG: Dynamic WSs may be dropped in the short term, or simply not be
precluded.
Default WS must be dynamic, else who would refresh it?
Make it so that WSs remember what you put into them. When you check in
something, the workspace remembers and keeps the resource in your WS. The
resource just becomes immutable, but still remains in your WS after checkin
(a good thing IMO).
*** Don't use 404 if resource revision isn't found?
When you do a CHECKIN, there is a checkin policy which specifies how the
checkin should be done in order to be successful. When you check in an
item, it provides a bunch of properties. If the properties can't be set,
or the server can't do what the properties specify, the checkin won't
succeed. Interim checkins (check this in, but I want to keep on working on
this resource). ***Should be inforced on both CHECKOUT and CHECKIN.
Advanced Versioning:
* Activity - some unit of work that you are doing (label of a line of
descent), multiple resources all associated with a change set.
* Workspace with RSR (Revision Selection Rule) (mutable set of revisions)
* Configuration - immutable set of revisions, like a product. Reproducable
set of revisions. Can version it, check it in.
* Merge - munge together 2 versions of a resource with different lines of
descent and bring the lines of descent back together until there's no more
conflicts. Can merge 2 workspaces together (catchup/release cycle).
* Versioned Collections
Activities:
MKRESOURCE explicit resource creation method (as opposed to a side effect
of a PUT). Create a resource and set its properties in one atomic
operation.
*** Eliminate idea of current activity and current label? Unnecessary with
static workspaces?
*** Activities are not really coupled to workspaces anymore.
Check out a number of resources within the context of the same activity.
Can create a "labeled configuration". Just add the same label to all the
desired revisions. (Can then move the label, thus no longer conforming
exactly to the configuration...)
Can add member revisions to a configuration.
public prototypes: mod_dav is open source. doesn't do anything with
versioning at the moment. written in C.
dav4j will be available as source soon. platform for exploration of
webdav.