Webdav/design/requirements.txt - zetacomponents - Git at Google

 eZ component: Webdav, Requirements
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 :Author:   Kore Nordmann, Tobias Schlitt
 :Revision: $Rev:$
 :Date:     $Date:$

 Introduction
 ============

 Description
 -----------

 The purpose of this component is acting as a webdav server, let clients
 download, upload and modify files from various sources.

 Requirements
 ============

 The first version of the component should support a filesystem as backend and
 make it easy to write own custom backends for the data storage of the
 webdav server. Imaginable are database backends, FTP-Servers and many more.

 A major problem to be solved by this component is, that most implementations of
 WebDAV clients violate the RFC, each in a different way. The component needs to
 abstract from these violation and to make it easy to support new clients. On
 each platform at least one client should be supported in the initial release,
 as there are:

 - Konqueror (Unix, KDE)
 - Nautilus (Unix, Gnome)
 - Internet Explorer, old and new implementation (Windows)
 - Finder (MacOS)

 Optionally:

 - Firefox (Multi platform)

 The default, RFC compliant, implementation must still be available and can be
 tested using cadaver, the most standard compliance webdav client available.

 Special Considerations
 ======================

 Clients & Datasources
 ---------------------

 The component should be flexible enough to easily add support for other
 misbehaving clients later, and to easily add other datasources then the
 filesystem backend. An solid abstraction of both tiers is the primary goal of
 this component.

 Dispatching
 -----------

 A developer integrating webdav using this component may want to use webdav as a
 front end for several types of data. The dispatching of URLs to different
 backends is task of the webserver, because it is capable of dispatching
 requests based on a URL (host, port, path, ..) to a different scripts which will
 perform as a webdav server for one single backend. Therefore dispatching will
 not be part of this component in any way.

 Locking
 -------

 We will support exclusive and shared locks directly in the server, including
 generation of unique lock tokens and lock timeouts. The server will store the
 lock state in a custom dead property resevered for this. The backend may
 overwrite the locking capabilities of the server, to implement custom group
 based shared locks, or exclusive lock mechanisms.

 Exclusive Locks
 	Write lock, so that only this pricipal may modify this ressource or
 	collection.

 Shared lock
     Everyone with write access to the ressource may still change the ressource
     or collection. The shared lock is just used as an indicator, that the
     ressource is in use by another person and that communication is required
     before performing any further change.

 Authentication
 --------------

 Authentication is key mechanism in webdav, especially when it comes to
 locking.  A lock persits on a per principal basis, so that each user is
 required to identify himself. The default authentication mechanism just
 authorizes every user to connect and read the contents.

 Optionally a ezcAuthenticationTiein may provide other authentication backends
 which may deny the connection to the webdav server. A possibility to distinct
 between interactive authentication mechanism (e.g. OpenID) and non-interactive
 mechanisms is required, because not every webdav client supports HTML.
 Therefore the Webdav component should only be capable of using non-interactive
 authenticiation methods.

 Authorization
 -------------

 The backend will handle the read / write authorization for its ressources and
 deny the access, if required.

 Metadata
 --------

 Webdav supports any kind of metadata in addition to the data required by the
 RFC, which is possible through costom or predefinde properties.  The storage of
 these properties needs to implemented by the server. The predefined properties,
 "live properties", needs to be validated by the server, while "dead
 properties", user / client defined ones, are left untouched by the server. The
 API of the backend classes still need a possibility to provide such dead
 properties and to react on properties defined by the client.

 It should be up to the storage backend to properly implement the storage of
 this data. For example, the filesystem backend may use XML files attached to
 the documents, or special file mechanisms like `XMP`__ to store the meta data
 directly in the file headers.

 __ http://wiki.creativecommons.org/XMP

 Extensions
 ----------

 Perhaps consider extensions of the Webdav protocol, like versioning and VCS
 support, to be easily integrated later.

 Terms
 =====

 Common WebDAV terms

 Collection
 	Corresponds to a directory in a file system. Contains a set of other
 	collections and / or ressources.

 Pricipal
 	Single user. May connect and act with multiple clients in parallel.

 Formats
 =======

 In the first iteration of the component we will implement `RFC 2518`__ with
 extensions for misbehaving clients.

 We will not support webdav extensions like distributed authoring and
 versioning defined in `RFC 3253`__ in the first stage, but keep these ideas in
 mind during the design phase.

 __ http://tools.ietf.org/rfc/rfc2518
 __ http://tools.ietf.org/rfc/rfc3253

 Other webdav related RFCs

 - `RFC 2291`__ - Requirements for a Distributed Authoring and Versioning
   Protocol for the World Wide Web
 - `RFC 2518`__ - HTTP Extensions for Distributed Authoring - WEBDAV
 - `RFC 3253`__ - Versioning Extensions to WebDAV
 - `RFC 3648`__ - Web Distributed Authoring and Versioning (WebDAV) Order
   Collections Protocol
 - `RFC 3744`__ - Web Distributed Authoring and Versioning (WebDAV) Access
   Control Protocol
 - `RFC 4316`__ - Datatypes for Web Distributed Authoring and Versioning
   (WebDAV) Properties
 - `RFC 4331`__ - Quota and Size Properties for Distributed Authoring and
   Versioning (DAV) Collections
 - `RFC 4437`__ - Web Distributed Authoring and Versioning (WebDAV) Redirect
   Reference Resources

 __ http://tools.ietf.org/rfc/rfc2291
 __ http://tools.ietf.org/rfc/rfc2518
 __ http://tools.ietf.org/rfc/rfc3253
 __ http://tools.ietf.org/rfc/rfc3648
 __ http://tools.ietf.org/rfc/rfc3744
 __ http://tools.ietf.org/rfc/rfc4316
 __ http://tools.ietf.org/rfc/rfc4331
 __ http://tools.ietf.org/rfc/rfc4437


 ..
    Local Variables:
    mode: rst
    fill-column: 79
    End:
    vim: et syn=rst tw=79
	eZ component: Webdav, Requirements
	~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	:Author: Kore Nordmann, Tobias Schlitt
	:Revision: $Rev:$
	:Date: $Date:$

	Introduction
	============

	Description
	-----------

	The purpose of this component is acting as a webdav server, let clients
	download, upload and modify files from various sources.

	Requirements
	============

	The first version of the component should support a filesystem as backend and
	make it easy to write own custom backends for the data storage of the
	webdav server. Imaginable are database backends, FTP-Servers and many more.

	A major problem to be solved by this component is, that most implementations of
	WebDAV clients violate the RFC, each in a different way. The component needs to
	abstract from these violation and to make it easy to support new clients. On
	each platform at least one client should be supported in the initial release,
	as there are:

	- Konqueror (Unix, KDE)
	- Nautilus (Unix, Gnome)
	- Internet Explorer, old and new implementation (Windows)
	- Finder (MacOS)

	Optionally:

	- Firefox (Multi platform)

	The default, RFC compliant, implementation must still be available and can be
	tested using cadaver, the most standard compliance webdav client available.

	Special Considerations
	======================

	Clients & Datasources
	---------------------

	The component should be flexible enough to easily add support for other
	misbehaving clients later, and to easily add other datasources then the
	filesystem backend. An solid abstraction of both tiers is the primary goal of
	this component.

	Dispatching
	-----------

	A developer integrating webdav using this component may want to use webdav as a
	front end for several types of data. The dispatching of URLs to different
	backends is task of the webserver, because it is capable of dispatching
	requests based on a URL (host, port, path, ..) to a different scripts which will
	perform as a webdav server for one single backend. Therefore dispatching will
	not be part of this component in any way.

	Locking
	-------

	We will support exclusive and shared locks directly in the server, including
	generation of unique lock tokens and lock timeouts. The server will store the
	lock state in a custom dead property resevered for this. The backend may
	overwrite the locking capabilities of the server, to implement custom group
	based shared locks, or exclusive lock mechanisms.

	Exclusive Locks
	Write lock, so that only this pricipal may modify this ressource or
	collection.

	Shared lock
	Everyone with write access to the ressource may still change the ressource
	or collection. The shared lock is just used as an indicator, that the
	ressource is in use by another person and that communication is required
	before performing any further change.

	Authentication
	--------------

	Authentication is key mechanism in webdav, especially when it comes to
	locking. A lock persits on a per principal basis, so that each user is
	required to identify himself. The default authentication mechanism just
	authorizes every user to connect and read the contents.

	Optionally a ezcAuthenticationTiein may provide other authentication backends
	which may deny the connection to the webdav server. A possibility to distinct
	between interactive authentication mechanism (e.g. OpenID) and non-interactive
	mechanisms is required, because not every webdav client supports HTML.
	Therefore the Webdav component should only be capable of using non-interactive
	authenticiation methods.

	Authorization
	-------------

	The backend will handle the read / write authorization for its ressources and
	deny the access, if required.

	Metadata
	--------

	Webdav supports any kind of metadata in addition to the data required by the
	RFC, which is possible through costom or predefinde properties. The storage of
	these properties needs to implemented by the server. The predefined properties,
	"live properties", needs to be validated by the server, while "dead
	properties", user / client defined ones, are left untouched by the server. The
	API of the backend classes still need a possibility to provide such dead
	properties and to react on properties defined by the client.

	It should be up to the storage backend to properly implement the storage of
	this data. For example, the filesystem backend may use XML files attached to
	the documents, or special file mechanisms like `XMP`__ to store the meta data
	directly in the file headers.

	__ http://wiki.creativecommons.org/XMP

	Extensions
	----------

	Perhaps consider extensions of the Webdav protocol, like versioning and VCS
	support, to be easily integrated later.

	Terms
	=====

	Common WebDAV terms

	Collection
	Corresponds to a directory in a file system. Contains a set of other
	collections and / or ressources.

	Pricipal
	Single user. May connect and act with multiple clients in parallel.

	Formats
	=======

	In the first iteration of the component we will implement `RFC 2518`__ with
	extensions for misbehaving clients.

	We will not support webdav extensions like distributed authoring and
	versioning defined in `RFC 3253`__ in the first stage, but keep these ideas in
	mind during the design phase.

	__ http://tools.ietf.org/rfc/rfc2518
	__ http://tools.ietf.org/rfc/rfc3253

	Other webdav related RFCs

	- `RFC 2291`__ - Requirements for a Distributed Authoring and Versioning
	Protocol for the World Wide Web
	- `RFC 2518`__ - HTTP Extensions for Distributed Authoring - WEBDAV
	- `RFC 3253`__ - Versioning Extensions to WebDAV
	- `RFC 3648`__ - Web Distributed Authoring and Versioning (WebDAV) Order
	Collections Protocol
	- `RFC 3744`__ - Web Distributed Authoring and Versioning (WebDAV) Access
	Control Protocol
	- `RFC 4316`__ - Datatypes for Web Distributed Authoring and Versioning
	(WebDAV) Properties
	- `RFC 4331`__ - Quota and Size Properties for Distributed Authoring and
	Versioning (DAV) Collections
	- `RFC 4437`__ - Web Distributed Authoring and Versioning (WebDAV) Redirect
	Reference Resources

	__ http://tools.ietf.org/rfc/rfc2291
	__ http://tools.ietf.org/rfc/rfc2518
	__ http://tools.ietf.org/rfc/rfc3253
	__ http://tools.ietf.org/rfc/rfc3648
	__ http://tools.ietf.org/rfc/rfc3744
	__ http://tools.ietf.org/rfc/rfc4316
	__ http://tools.ietf.org/rfc/rfc4331
	__ http://tools.ietf.org/rfc/rfc4437


	..
	Local Variables:
	mode: rst
	fill-column: 79
	End:
	vim: et syn=rst tw=79