Goals for a Configuration Management Network Protocol

Jim WhiteheadUniv. of California, Irvine

SCM-9, September 7, 1999

Talk Overview

Brief overview of WebDAV Web Distributed Authoring and Versioning But, only was able to finish the “DA” part

Provide a scenario of use for Delta-V A network protocol for remote versioning and

configuration management A standards effort within the IETF

Present important goals for Delta-VOutline significant Delta-V design elements

Style of work, workspaces, activities

The WebDAV Protocol

Extends the core network protocol of the Web, Hypertext Transfer Protocol (HTTP) Leverages popularity (read: network effects) of

existing Web technologyProvides remote authoring of Web

resources directly on a Web server Turns the Web into a writeable, collaborative

mediumA standard mechanism by which authoring

tools and servers can be compatible Compatibility leads to network effects

WebDAV Capabilities

Overwrite Prevention Whole resource locks prevent overwrite

conflictsProperties

Attribute-value pairs for storing metadataNamespace Management

Hierarchical navigation of Web resources Create new collections

Scope of WebDAV Methods

Web Resource

Body(primary

state)

Properties(name, value)

pairsLOCKUNLOCKCOPYMOVE†

DELETE†

MKCOL†

(PUT†)

PROPFIND

PROPPATCH†

GET

PUT†

† - affected by

LOCK

WebDAV Clients and Servers

Clients Office 2000 Internet Explorer 5 WebDAV Explorer Sitecopy DAV4J (Java API)

Servers Internet Information

Services 5 Apache mod_dav DAV4J Zope WebRFM Xythos Storage Server Glyphica PortalWare CyberTeams WebSite

Director Lite Intraspect Knowledge

Server

Delta-V Use Scenario

You’re an employee of a small design firm called DesignHaus Working on a very time sensitive Web site

updateDesignHaus draws its talent from around

the world The team is active 24 hours a day

Tokyo: Kenji supplies graphics and iconsParis: Denise performs page layout using XSLNew York: Peter writes database to Web glue codeLos Angeles: you’re in charge of XML site content

Delta-V Use Scenario (2)

After finishing a phone call with the client, you start editing an XML product information description

From XML-Author, your XML authoring tool, choose File… Open Using Delta-V protocol, XML-Author performs a check-out

protocol operation XML-Author discovers Denise is already working on the

same file - pops up a dialog box No problem, you decide to work in parallel with Denise

since she is working on layout, not content, hence changes shouldn’t overlap much

XML-Author sends request to download page, and displays it on the screen.

Delta-V Use Scenario (3)

Once you’ve finished your changes… Select “File… Commit” in XML-Author XML-Author saves final version (HTTP PUT) XML-Author sends network request to perform

a check-in Check-in succeeds, and XML-Author discovers

Denise has also committed her changesPops up a dialog box asking if you want to merge

your changes with Denise’sYou select “yes”, starting merge process

Delta-V Use Scenario (4)

XML-Author downloads Denise’s latest revision, and brings up a graphical merge tool Using the merge tool, you decide which

changes to accept, or reject. When done, select “File… Commit”, and XML-

Author makes the necessary protocol requests to write the merged revision, and check it in

Since you’ve been editing in-place on the Web, you’re now ready to call back your client with the latest changes…

Primary Goals for Delta-V

Provide versioning services Persistent storage of previous revisions of resources Retrieve history list Submit comments with changes

Parallel development Allow two or more people to work simultaneously

Group changes Gather the low-level changes required to perform a

logical changeConfiguration management

Versioned sets of versioned resources

Delta-V Goals

Equal support for all content types Not just versioning of text!

Versioning aware and non-versioning aware clients must interoperate Existing DAV clients (like Office 2000) need

to be able to participate in versioning services

Perform versioning automatically for them

Delta-V Goals (cont’d)

Configuration management capability is an optional extension to versioning capability Layer 1: versioning Layer 2: configuration management

Authoring tools typically only need versioning capabilities

More sophisticated tools (programming environments) need configuration management capabilities

Some repositories are only capable of versioning

Delta-V Goals (cont’d)

It must be possible to link to every revision of a resource Implies that every revision has a distinct URL

Versioning should not disrupt relative URLs Corollary: if a set of resources is arranged in a

hierarchy before they are placed under version control, the hierarchy should be the same after the resources are under version control

There is a tension between these requirements Separate edit URL space and revision URL space

Delta-V Goals (cont’d)

Revisions may be mutable or immutable Software development has typically involved

immutable revisions Document management can be more relaxed

Sometimes it isn’t a requirement to track every changeCan be more important to preserve logical name of a

revision “June Sales Brochure”Users don’t want mutable revisions to be emulated by

immutable revisions• The intent of mutable revisions is to avoid making a new

revision for a small change, like a spelling correction

Mutable revisions will likely not be members of configurations

Delta-V Goals (cont’d)

Some properties on revisions can be changed without creating a new revision Two kinds of properties

Metadata about the resourceMetadata used for protocol operations

• Must be able to modify this type (access permissions)

Delta-V Goals (cont’d)

Internationalization Internet is used worldwide Needs to accommodate human

languages in current (and even past) use Affects revision labels

Security Need strong authentication Need transport security

Concepts: Versioned Resource

Foo.htm

1

2

7

65

43

initial

Beta1

Test1

Beta2

VersionedResource

Revision Id

RevisionLabel

Successors

Line ofDescent

RevisionHistory

PredecessorsSource: Chris Kaler

Concepts: Checkin and Checkout

WorkingResource

Checkout Checkin

Foo.htm

1

2

Foo.htm

1

2

Foo.htm

1

2

3

Source: Chris Kaler

Revision Operations

Create a versioned resource from an unversioned resource Set its initial revision value to the contents of the

unversioned resourceCheck-out a revision in an activityCheck-in a resource and either create a new

revision (immutable revisions) or update the existing revision in place (mutable revisions)

Cancel a check-outDescribe a revision with comments

Label Operations

Apply a label to a particular revisionChange the revision to which a label

refersRetrieve all labels on a particular

revision

Concepts: Activity and Configuration

Foo.htm

1

2

3

Activity: set of related changes

Bar.htm

1

2

3 Configuration: specific set of revisions

activity1activity1

activity2activity3

Source: Chris Kaler

Concepts: WorkspaceBar.xml

2

Foo.dtd Workspace Configurable view of

the versioned resources

Revision selection rule (RSR) selects the revisions

Gives each person/team a separate work area

3

1

4

2

3

1

Car.xml

2

1

Workspace 2Bar.xml, v4Foo.dtd, v3Car.xml, wrk

Workspace 1Bar.xml, wrkFoo.dtd, v3Car.xml, v2

Activity Operations

Create and name an activityCheck-out a revision in an activityMerge an activity into a workspace

Possibly creating a conflict reportGet a list of resources modified in an

activityApply a label operation to all

resources in an activity

Configuration Operations

Create/delete a configurationAdd/remove revisions from a configurationUse a configuration in a workspace’s

revision selection rule to choose revisions in that configuration

Determine the differences between two configurations by listing the activities in one, and not the other.

Acknowledgements

The paper reports on the requirements document of the Delta-V working group I am not the sole author of this document Other contributors: Jim Amsden, Chris Kaler, John

Stracke, Bradley Sergeant, Geoff Clemm, David Durand, Alan Babich, Bruce Cragun, Jeff McAffer

Was also based on the earlier WeBDAV requirements document, with authors: Judy Slein, Fabio Vitali, David Durand

WebDAV design team also contributed: Yaron Goland, Del Jensen, Steve Carter, Asad

Faizi

For More Information…

WebDAV Resources www.webdav.org

Delta-V Working Group www.webdav.org/deltav/

WebDAV Working Group www.ics.uci.edu/pub/ietf/webdav/