1 / 27

Goals for a Configuration Management Network Protocol

Goals for a Configuration Management Network Protocol. Jim Whitehead Univ. of California, Irvine SCM-9 , September 7, 1999. Talk Overview. Brief overview of WebDAV Web D istributed A uthoring and V ersioning But, only was able to finish the “DA” part

gisela-davis
Télécharger la présentation

Goals for a Configuration Management Network Protocol

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Goals for a Configuration Management Network Protocol Jim Whitehead Univ. of California, Irvine SCM-9, September 7, 1999

  2. 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-V • Outline significant Delta-V design elements • Style of work, workspaces, activities

  3. The WebDAV Protocol • Extends the core network protocol of the Web, Hypertext Transfer Protocol (HTTP) • Leverages popularity (read: network effects) of existing Web technology • Provides remote authoring of Web resources directly on a Web server • Turns the Web into a writeable, collaborative medium • A standard mechanism by which authoring tools and servers can be compatible • Compatibility leads to network effects

  4. WebDAV Capabilities • Overwrite Prevention • Whole resource locks prevent overwrite conflicts • Properties • Attribute-value pairs for storing metadata • Namespace Management • Hierarchical navigation of Web resources • Create new collections

  5. Scope of WebDAV Methods Web Resource PROPFIND PROPPATCH† Properties (name, value) pairs LOCK UNLOCK COPY MOVE† DELETE† MKCOL† (PUT†) Body (primary state) GET PUT† † - affected by LOCK

  6. 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 WebDAV Clients and Servers

  7. Delta-V Use Scenario • You’re an employee of a small design firm called DesignHaus • Working on a very time sensitive Web site update • DesignHaus draws its talent from around the world • The team is active 24 hours a day • Tokyo: Kenji supplies graphics and icons • Paris: Denise performs page layout using XSL • New York: Peter writes database to Web glue code • Los Angeles: you’re in charge of XML site content

  8. 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.

  9. 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 changes • Pops up a dialog box asking if you want to merge your changes with Denise’s • You select “yes”, starting merge process

  10. 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…

  11. 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 change • Configuration management • Versioned sets of versioned resources

  12. 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

  13. 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

  14. 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

  15. 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 change • Can 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

  16. Delta-V Goals (cont’d) • Some properties on revisions can be changed without creating a new revision • Two kinds of properties • Metadata about the resource • Metadata used for protocol operations • Must be able to modify this type (access permissions)

  17. 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

  18. Concepts: Versioned Resource Versioned Resource Foo.htm 1 initial Line of Descent Beta1 2 Revision History Revision Id 3 4 Revision Label 5 6 Test1 7 Beta2 Successors Predecessors Source: Chris Kaler

  19. Foo.htm Foo.htm 1 1 2 2 3 Concepts: Checkin and Checkout Checkout Checkin Foo.htm 1 2 Working Resource Source: Chris Kaler

  20. Revision Operations • Create a versioned resource from an unversioned resource • Set its initial revision value to the contents of the unversioned resource • Check-out a revision in an activity • Check-in a resource and either create a new revision (immutable revisions) or update the existing revision in place (mutable revisions) • Cancel a check-out • Describe a revision with comments

  21. Label Operations • Apply a label to a particular revision • Change the revision to which a label refers • Retrieve all labels on a particular revision

  22. Concepts: Activity and Configuration Foo.htm Bar.htm 1 1 Activity: set of related changes activity1 activity1 2 2 activity3 activity2 3 Configuration: specific set of revisions 3 Source: Chris Kaler

  23. 1 1 1 2 2 2 3 4 3 Concepts: Workspace Car.xml Foo.dtd Bar.xml • Workspace • Configurable view of the versioned resources • Revision selection rule (RSR) selects the revisions • Gives each person/team a separate work area Workspace 1 Bar.xml, wrk Foo.dtd, v3 Car.xml, v2 Workspace 2 Bar.xml, v4 Foo.dtd, v3 Car.xml, wrk

  24. Activity Operations • Create and name an activity • Check-out a revision in an activity • Merge an activity into a workspace • Possibly creating a conflict report • Get a list of resources modified in an activity • Apply a label operation to all resources in an activity

  25. Configuration Operations • Create/delete a configuration • Add/remove revisions from a configuration • Use 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.

  26. 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

  27. 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/

More Related