\documentclass{article}
\usepackage{ulem}
\usepackage{graphicx}
\usepackage{hyperref}
\pagestyle{headings}
\begin{document}
\part{Developer Notes on <a href="https://wiki.horde.org/WebDAV">WebDAV</a> and <a href="https://wiki.horde.org/CalDAV/CardDAV">CalDAV/CardDAV</a> 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:

\begin{itemize}
\item <a href="https://wiki.horde.org/CalDAV">CalDAV</a> and <a href="https://wiki.horde.org/CardDAV">CardDAV</a> are tied to the applications implementing the calendar/ and addressbooks/ api's


\item Generic <a href="https://wiki.horde.org/WebDAV">WebDAV</a> hierarchies may be implemented by any application.


\end{itemize}
\section{Horde\_Dav and <a href="https://wiki.horde.org/SabreDAV">SabreDAV</a>}
Horde DAV support is implemented based on the <a href="https://wiki.horde.org/SabreDAV">SabreDAV</a> library. As of 2018, it's <a href="https://wiki.horde.org/SabreDAV">SabreDAV</a> 2.1

<a href="https://wiki.horde.org/SabreDAV">SabreDAV</a> is wrapped in Horde\_Dav. Horde\_Dav implements or extends various interfaces and base classes used by <a href="https://wiki.horde.org/SabreDAV">SabreDAV</a>.<br />
Horde\_Auth is wrapped into Horde\_Dav\_Auth which extends the abstract <a href="https://wiki.horde.org/SabreDAV">SabreDAV</a> auth backend.<br />
Horde\_Dav\_RootCollection implements a top node for a hierarchy of Horde\_Dav\_Collection items (DAV folders)<br />
Horde\_Dav\_Principals exposes users and groups as (principials) to <a href="https://wiki.horde.org/SabreDAV">SabreDAV</a>.<br />
Shares/Resources owned by the system use the empty string in the horde shares backend, but use the string -system- in <a href="https://wiki.horde.org/SabreDAV">SabreDAV</a> context. This conversion needs to be done by the implementing app, not by Horde\_Dav.<br />
Horde\_Dav\_File implements a leaf node in DAV (a file)

\section{<a href="https://wiki.horde.org/CalDAV">CalDAV</a> and <a href="https://wiki.horde.org/CardDAV">CardDAV</a>}
The Horde\_Dav caldav and <a href="https://wiki.horde.org/CardDAV">CardDAV</a> 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<br />
rpc/addressbooks/<br />
rpc/calendars/<br />
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?

\subsection{<a href="https://wiki.horde.org/CalDAV">CalDAV</a> specifics}
The <a href="https://wiki.horde.org/CalDAV">CalDAV</a> 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 <a href="https://wiki.horde.org/CalDAV">CalDAV</a>.

\subsection{<a href="https://wiki.horde.org/CardDAV">CardDAV</a> specifics}
The <a href="https://wiki.horde.org/CardDAV">CardDAV</a> addressbooks backend relies on registry Api calls to whatever application implements the contacts api. Thus, only one application can interface addressbooks to <a href="https://wiki.horde.org/CardDAV">CardDAV</a>. However, that application may or may not implement interfacing resources exposed by other apps. The default app to expose addressbooks is turba.

Flow:

horde/rpc determines it is a webdav call and starts a Horde\_Rpc\_Webdav instance.<br />
This wraps Horde\_Dav\_Server, which is a <a href="https://wiki.horde.org/SabreDAV">SabreDAV</a> server with a Horde\_Dav <a href="https://wiki.horde.org/CardDAV">CardDAV</a> backend.<br />
This carddav backend is an app which implements the dav* methods in Application.php<br />
<a href="https://wiki.horde.org/SabreDAV">SabreDAV</a> will handle the request and provide an answer to horde/rpc, using the Horde app as its storage backend.

\section{<a href="https://wiki.horde.org/WebDAV">WebDAV</a>}
Generic <a href="https://wiki.horde.org/WebDAV">WebDAV</a> can be implemented by any app.<br />
It is exposed as rpc/\$appname/ in the tree. Note how it uses the internal app name, not the name of a registry interface.<br />
An app needs to implement the following API methods to expose <a href="https://wiki.horde.org/WebDAV">WebDAV</a> folders and files:

\$App\_Api::browse(\$path, \$properties)

returns a list of next level nodes relative to the path (files and collections)

\$App\_Api::put(\$path, \$content, \$contentType)

to support writing files

path\_delete(\$path) to delete either files or collections

The app implementing these methods does not need to deal with any of the Horde\_Dav related objects as Horde\_Rpc\_WebDAV and Horde\_Dav handle these aspects.<br />
However, if the same resources are also exposed via <a href="https://wiki.horde.org/CalDAV/CardDAV">CalDAV/CardDAV</a> Api, it might create inconsistency if a resource is created or deleted without Horde\_Dav knowing.

\section{Notes on *dav lingo and principles}
\end{document}
