aboutsummaryrefslogtreecommitdiff
path: root/doc/ref/webdav.texi
blob: 991a15b15a3a4c3798c5a8090377ae9ef9fd1436 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
@node WebDAV
@chapter WebDAV

For a complete view of WebDAV, please see @cite{RFC4918 (HTTP
Extensions for Web Distributed Authoring and Versioning (WebDAV))},
but in short, and specifc for this implementation.

A DAV tree consists of resources, which are analogous to files and
directories. A resource is referenced by its href.

Each resources is either a collection and have children, or have
content. Parts of this implementation allows a collection to also have
contents, while other does not. The standard doesn't seem to mind
either way.

Each resource also has a set of properties, modelling metadata and
extra data about the resource.

@emph{href}'s are internally represented as lists of strings, where the
root element ``/'' is an empty list, and all other cases are mapped
like:
@example
"/a/b" ⇒ '("a" "b")
@end example

@emph{resources} are GOOPS objects, which the base class
@code{<resource>}.

The user (of the library) is assumed to designate one resource
instance as the root of the resource tree. All other resources are
then added as (grand-)children to that resource. Each resource has a
field @var{name}, which is the normative name used when searching by
name in the tree@footnote{This means that one resource can't easily
exist at multiple points in the tree}.

@emph{properties} are split into live and dead properties, where live
properties have extra handling by the server, while dead properties
are simply carried along after the end-user put them on a resource.

Live properties are handled through GOOPS methods.

Dead properties are (by default) stored directly inside each resource.

@include webdav/properties.texi
@include webdav/resources.texi
@include webdav/resource-types.texi
@include webdav/util.texi