Virtual WebDAV provider


Given these 3 ‘resources’:

Title Orga Status Tags Attachments
My doc 1 development draft cool, hot MySpec.doc MySpec.pdf
My doc 2 development published cool, nice MyURS.doc
My doc (.) marketing published nice MyURS.doc

this dynamic structure is published:


A resource is served as an collection, which is generated on-the-fly and contains some virtual files with additional information:



To publish the sample virtual resources, simply add thes lines to the configuration file:

# Publish a virtual structure
from wsgidav.samples.virtual_dav_provider import VirtualResourceProvider
addShare("virtres", VirtualResourceProvider())

Module description

Sample implementation of a DAV provider that provides a browsable, multi-categorized resource tree.

Note that this is simply an example with no concrete real world benefit. But it demonstrates some techniques to customize WsgiDAV.

Compared to a published file system, we have these main differences:

  1. A resource like My doc 1 has several attributes like key, orga, tags, status, description. Also there may be a list of attached files.
  2. These attributes are used to dynamically create a virtual hierarchy. For example, if status is draft, a collection <share>/by_status/draft/ is created and the resource is mapped to <share>/by_status/draft/My doc 1.
  3. The resource My doc 1 is rendered as a collection, that contains some virtual descriptive files and the attached files.
  4. The same resource may be referenced using different paths For example <share>/by_tag/cool/My doc 1, <share>/by_tag/hot/My doc 1, and <share>/by_key/1 map to the same resource. Only the latter is considered the real-path, all others are virtual-paths.
  5. The attributes are exposed as live properties, like “{virtres:}key”, “{virtres:}tags”, and “{virtres:}description”. Some of them are even writable. Note that modifying an attribute may also change the dynamically created tree structure. For example changing “{virtres:}status” from ‘draft’ to ‘published’ will make the resource appear as <share>/by_status/published/My doc 1.
  6. This provider implements native delete/move/copy methods, to change the semantics of these operations for the virtual ‘/by_tag/’ collection. For example issuing a DELETE on <share>/by_tag/cool/My doc 1 will simply remove the ‘cool’ tag from that resource.
  7. Virtual collections and artifacts cannot be locked. However a resource can be locked. For example locking <share>/by_tag/cool/My doc 1 will also lock <share>/by_key/1.
  8. Some paths may be hidden, i.e. by_key is not browsable (but can be referenced) TODO: is this WebDAV compliant?

The database is a simple hard coded variable _resourceData, that contains a list of resource description dictionaries.

A resource is served as an collection, which is generated on-the-fly and contains some virtual files (artifacts).

In general, a URL is interpreted like this:


An example layout:

            My doc 1/
            My doc 2/
            My doc 1/
            My doc 2/
            My doc 2/
            My doc 3
            My doc 3/
            My doc 1/
            My doc 2/
            My doc 2
            My doc 1
            My doc 3

When accessed using WebDAV, the following URLs both return the same resource ‘My doc 1’:

<share>/by_tag/cool/My doc 1
<share>/by_tag/hot/My doc 1