Www distributed authoring and versioning webdav an introduction
Download
1 / 34

WWW Distributed Authoring and Versioning (WEBDAV ): An Introduction - PowerPoint PPT Presentation


  • 102 Views
  • Uploaded on

WWW Distributed Authoring and Versioning (WEBDAV ): An Introduction. Jim Whitehead, U.C. Irvine Chair, IETF WEBDAV Working Group. What is WEBDAV?. Working Group on D istributed A uthoring and V ersioning on the World Wide Web

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' WWW Distributed Authoring and Versioning (WEBDAV ): An Introduction' - ingrid-carpenter


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Www distributed authoring and versioning webdav an introduction

WWW Distributed Authoring and Versioning (WEBDAV ): An Introduction

Jim Whitehead, U.C. Irvine

Chair, IETF WEBDAV

Working Group


What is webdav
What is WEBDAV?

Working Group on Distributed Authoring and Versioning on the World Wide Web

Goal:To enable distributed web authoring tools to be broadly interoperable.

Home page:

http://www.ics.uci.edu/~ejw/authoring/


Facets of webdav
Facets of WEBDAV

  • There are many ways to view the DAV work:

    • Collaboration infrastructure

    • Metadata recording infrastructure

    • Hypermedia infrastructure

    • Namespace management infrastructure

    • Versioning infrastructure


Collaboration infrastructure
Collaboration Infrastructure

  • Whole resource locking supports:

    • remote collaborative authoring of HTML pages and associated images

    • remote collaborative authoring of any media type (word processing, presentations, etc.)

  • Infrastructure for development of asynchronous, widely distributed, hypertext-aware, collaborative editing tools.


Metadata recording infrastructure
Metadata Recording Infrastructure

  • Metadata support

    • Properties. (name, value) pairs can be created, modified, deleted, and read on Web resources.

    • Consistency of properties can be maintained by the server or the client

  • Infrastructure for how to record information about Web data


Hypermedia infrastructure
Hypermedia Infrastructure

  • Hypermedia linking:

    • Relationships. Allow relations between resources to be captured (e.g. source code “implements” requirements, “table of contents”)

    • Relationships can be defined on any media type, not just HTML.

    • Clients can expose relationships in their user interface, making them browsable hypermedia links

  • Infrastructure for authoring hypermedia among all media types.


Namespace management infrastructure
Namespace Management Infrastructure

  • Remote name space management:

    • Copy resources

    • Move resources

    • Create and modify containers of resources (such as directories)

    • Redirect queries for resources

  • Infrastructure for remotely organizing and viewing collections of Web resources


Versioning infrastructure
Versioning Infrastructure

  • Versioning is integral

    • check-out, check-in

    • version graph history

    • comments on check-out/check-in

    • server merge/difference

    • browse old versions

  • Infrastructure for remotely versioning Web resources


Requirements
Requirements

  • Requirements Document

    • High-level distributed authoring and versioning requirements

    • Editor: Judith Slein, Xerox

    • Began working group last call on September 3, 1997

    • Call for consensus, submission to IESG in late September


Protocol
Protocol

  • Protocol Specification

    • Specifies details of extensions to HTTP protocol to meet requirements

    • Covers properties, collections, namespace operations, locking (perhaps versioning)

    • Currently at draft-ietf-webdav-protocol-02.txt

    • Editor: Del Jensen, Novell

    • Next release: September 24, 1997


Scenarios
Scenarios

  • Scenarios document

    • Gathers scenarios of usage of distributed authoring and versioning technology as a sanity check for requirements, protocol specification

    • Editor: Ora Lassila, Nokia


Access control
Access Control

  • Access Control Document

    • Currently working on access control requirements

    • Jon Radoff, Novalink is current editor, but has not responded to email status inquiries

    • Goal: finish requirements and protocol aspects by June 1998


Recursive operations
Recursive Operations

  • Recursive Operations Specification

    • Describes how to perform copy, move, lock for a tree structure of resources (a direct containment hierarchy)

    • Saveen Reddy, Microsoft is editor

    • Goal: finish by April, 1998


Variants specification
Variants Specification

  • Variants Specification

    • Will describe requirements for authoring resource variants

    • Specify protocol elements needed to support authoring of resource variants

    • No editor yet chosen

    • Goal: August, 1998


Getting involved
Getting Involved

  • How do you join the WEBDAV Working Group?

    • Join the mailing list ([email protected])

    • Send message with subject “subscribe” to [email protected]

  • Attend a working group meeting

  • Next scheduled meeting: Washington, DC IETF, December, 1997.


Requirements1

Requirements

Overview of Requirements from draft-ietf-webdav-requirements-02.txt


Metadata requirements
Metadata Requirements

  • Properties. It must be possible to create, modify, query, read and delete arbitrary properties on resources of any media type.

  • Relationships. It must be possible to create, modify, read and delete typed links between resources of any media type.


Collection requirements
Collection Requirements

  • List Collection. A listing of all resources in a specific collection must be accessible.

  • Make Collection. It must be possible to create a new collection.

  • Add to Collection. It must be possible to add a resource to a collection directly or by reference.


Collection requirements cont d
Collection Requirements (cont’d)

  • Remove from Collection. It must be possible to remove a resource from a collection. In the case of a resource that belongs to the collections directly, this results in the resource being deleted. In the case of a resource that is merely referenced by the collection, only the reference is removed.


Copy requirements
Copy Requirements

  • Copy. It must be possible to duplicate a resource without a client loading, then resaving the resource.

    • After the copy operation, the content of the destination resource must be octet for octet identical to the content of the source resource.

    • A modification to either resource must not cause a modification to the other.


Move requirements
Move Requirements

  • Move/Rename. It must be possible to change the location of a resource without a client loading, the resaving the resource under a different name.

    • After the move operation, the content of the resource at its new location must be octet for octet identical to the content of the prior resource.

    • It must no longer be possible to access the resource at its original location.

    • The move operation should leave an audit trail.


Locking principles
Locking Principles

  • Independence of locks. It must be possible to lock a resource without re-reading the resource and without committing to editing the resource.

  • Multi-resource locking. It must be possible to take out a lock on multiple resources on the same server in a single action, and this locking operation must be atomic across these resources.


Locking requirements
Locking Requirements

  • Write Locks. It must be possible to restrict modification of a resource to a specific person.

  • Lock Query. It must be possible to find out whether a given resource has any active locks, and if so, who holds those locks.

  • Unlock. It must be possible to remove a lock.


Reservation requirements
Reservation Requirements

  • Reserve. It must be possible for a principal to register with the server an intent to edit a given resource, so that other principals can discover who intends to edit the resource.

  • Reservation Query. It must be possible to find out whether a given resource has any active reservations, and if so, who currently holds reservations.

  • Release Reservation. It must be possible to release the reservation.


Miscellaneous requirements
Miscellaneous Requirements

  • Source Retrieval.The source of any given resource must be retrievable.

  • Partial Write. After editing a resource, it must be possible to only write the changes to the resource, rather than retransmitting the entire resource.


Versioning principles
Versioning Principles

  • Stability of versions. A client must be able to determine that a version has been frozen. Any successful attempt to retrieve a frozen version of a resource will always retrieve exactly the same content.

  • Versioning Policies. The protocol should identify the policies that it dictates and the policies that are left up to the versioning system implementors or administrators.


Versioning principles1
Versioning Principles

  • Media Type Independence. It is possible to version resources of any media type.


Version topology requirements
Version Topology Requirements

  • Version topology. The collection of related versions of a resource forms a directed acyclic graph (known as a “version graph”)

  • Version graph distribution. It should be possible for a version graph to span multiple servers.

  • Version graph handle. There must be a way to refer to the version graph as a whole.


Version graph retrieval requirements
Version Graph Retrieval Requirements

  • Version graph retrieval. There must be a way to retrieve the complete version topology for a version graph.

  • Default version. There must be a way to assign a default member of a version graph for retrieval.


Version graph navigation requirements
Version Graph Navigation Requirements

  • Navigation. Given a reference to a member of a version graph, it must be possible to discover and access the following:

    • root member of the graph

    • predecessor member(s)

    • successor member(s)

    • default member of the graph


Uniqueness addressability requirements
Uniqueness/Addressability Requirements

  • Uniqueness of version identifier. A version identifier must be unique across a version graph.

  • Addressability. All versions of a resource are themselves resources, and are individually addressable.


Versioning session requirements
Versioning Session Requirements

  • Check-out/Check-in. It should be possible to check-out, and then check-in a resource.

  • Session tracking. It must be possible for a client to query the server for information about a version tree, including which versions are locks, which are reserved for editing, and by whom.

  • Comments. It should be possible to assign comments on a check-out or check-in.


Difference merge requirements
Difference/Merge Requirements

  • Server difference. It must be possible for a client to retrieve a list of differences between two or more resources of the same media type.

  • Server merge. A client must be able to request that the server merge two or more resources, and return the results of the merge to the client, or store the result as a resource. Server support for this functionality must be optional.



ad