Goals for a Configuration Management Network Protocol Jim Whitehead Univ. of California, Irvine SCM-9, September 7, 1999
Jan 03, 2016
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