www distributed authoring and versioning webdav an introduction
Download
Skip this Video
Download Presentation
WWW Distributed Authoring and Versioning (WEBDAV ): An Introduction

Loading in 2 Seconds...

play fullscreen
1 / 34

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


  • 103 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?
  • 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