Virtual WebDAV provider

Examples

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:

Usage

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:

<share>/<category-type>/<category-key>/<resource-name>/<artifact-name>

An example layout:

<share>/
    by_tag/
        cool/
            My doc 1/
                .Info.html
                .Info.txt
                .Description.txt
                MySpec.pdf
                MySpec.doc
            My doc 2/
        hot/
            My doc 1/
            My doc 2/
        nice/
            My doc 2/
            My doc 3
    by_orga/
        development/
            My doc 3/
        marketing/
            My doc 1/
            My doc 2/
    by_status/
        draft/
            My doc 2
        published/
            My doc 1
            My doc 3
    by_key/
        1/
        2/
        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
<share>/by_key/1