[commits] [Wiki] created: Doc/Dev/DAV/DeveloperNotes

[Ralf Lang (B1 Systems GmbH)]

rlang  Thu, 10 Jan 2019 10:47:35 +0000

Created page: https://wiki.horde.org/Doc/Dev/DAV/DeveloperNotes

+ Developer Notes on WebDAV and CalDAV/CardDAV Support in Horde

This page is mostly based on Horde 5 and Horde master as of 12/2018

Horde offers two different DAV endpoint types:

- CalDAV and CardDAV are tied to the applications implementing the  
calendar/ and addressbooks/ api's
- Generic WebDAV hierarchies may be implemented by any application.

++ Horde_Dav and SabreDAV
Horde DAV support is implemented based on the SabreDAV library. As of  
2018, it's SabreDAV 2.1

SabreDAV is wrapped in Horde_Dav. Horde_Dav implements or extends  
various interfaces and base classes used by SabreDAV.
Horde_Auth is wrapped into Horde_Dav_Auth which extends the abstract  
SabreDAV auth backend.
Horde_Dav_RootCollection implements a top node for a hierarchy of  
Horde_Dav_Collection items (DAV folders)
Horde_Dav_Principals exposes users and groups as (principials) to SabreDAV.
Shares/Resources owned by the system use the empty string in the horde  
shares backend, but use the string -system- in SabreDAV context. This  
conversion needs to be done by the implementing app, not by Horde_Dav.
Horde_Dav_File implements a leaf node in DAV (a file)


++ CalDAV and CardDAV

The Horde_Dav caldav and CardDAV backends is accessed through the  
horde/base app's rpc endpoint /rpc/ or /rpc.php depending on config.  
This endpoint detects DAV and exposes three hierarchies
rpc/addressbooks/
rpc/calendars/
rpc/principals/

Horde_Dav_Storage maps the exposed name of caldav and carddav leaf  
objects (files) to collections.

TODO: How are resources handled when they exist internally but the  
mapping is missing for some reasons like admin meddling in DB?

+++ CalDAV specifics
The CalDAV calendars backend relies on registry Api calls. Most of the  
code delegates finding the implementing horde app for a specific  
resource to the storage implementation's getCollectionInterface()  
method. However, the constructor explicitly only looks for the apps  
implementing the calendar api (kronolith) and the tasks api (nag). If  
another app implements the respective API's, it can substitute any of  
the two as a backend. However, it's currently not possible to directly  
expose a third app's resources to caldav. However, there is work to  
make kronolith expose other applications' timeobjects to caldav as a  
pass-through, just like in UI.

Currently, Horde_Dav does not allow adding new collections via CalDAV.

+++ CardDAV specifics

The CardDAV addressbooks backend relies on registry Api calls to  
whatever application implements the contacts api. Thus, only one  
application can interface addressbooks to CardDAV. However, that  
application may or may not implement interfacing resources exposed by  
other apps. The default app to expose addressbooks is turba.


++ WebDAV

Generic WebDAV can be implemented by any app.
It is exposed as rpc/$appname/ in the tree. Note how it uses the  
internal app name, not the name of a registry interface.
An app needs to implement the following methods to expose WebDAV  
folders and files:



++ Notes on *dav lingo and principles