DAViCal

DAViCal is a self‑hosted CalDAV server written in PHP that exposes calendar data stored in an SQL database (primarily PostgreSQL) over the CalDAV protocol. From a developer’s point of view, it functions as a thin HTTP layer that translates CalDAV requests into database operations while preserving the semantics of iCalendar. The server supports full CRUD on calendar objects, ACL delegation, and scheduling features such as free‑busy queries and meeting invitations. Because it implements the CalDAV spec, any client that speaks CalDAV—Mozilla Lightning, Evolution, Apple Calendar, and many others—can interact with DAViCal without modification.

Architecture & Technical Stack

• Language & Runtime: PHP 5.x (the source states “PHP version 5”), which means the codebase relies on procedural PHP with a handful of classes for routing and database abstraction.
• Frameworks: No full MVC framework; the project uses its own lightweight request router and a custom template engine.
• Persistence: PostgreSQL is the recommended backend, though any SQL‑compliant database can be used with minimal changes. Tables store calendar resources (calendar, event), ACL entries, and scheduling metadata.
• Web Server: Apache or Nginx with mod_php/PHP‑FPM, exposing the /davicallib directory as a CalDAV endpoint.
• WebDAV Layer: The server implements WebDAV for backward compatibility, allowing legacy clients to perform read‑only or read‑write operations over HTTP methods (PROPFIND, PUT, DELETE).

The architecture is intentionally simple: an HTTP request → CalDAV handler → SQL transaction. This minimalism keeps the codebase lightweight and makes it easier to audit for security or performance.

Core Capabilities & APIs

• CalDAV Compliance: Full support for REPORT, PROPFIND, PUT/POST on calendar collections, and DELETE.
• ACL & Delegation: Users can grant read/write access to other users, enabling shared calendars and collaborative scheduling.
• Scheduling: Implements the free-busy report, allowing clients to query availability across multiple calendars.
• iCalendar Support: Events are stored as VEVENT components; recurrence rules (RRULE) and time zone information are preserved.
• Extensibility Hooks: The source exposes a small set of hooks (e.g., beforeEventCreate, afterEventDelete) that developers can override by subclassing the core handler or inserting custom PHP files in a designated plugins directory.

These APIs are exposed purely over HTTP; there is no separate REST or GraphQL interface, so developers who need programmatic access typically interact with the CalDAV endpoints directly using libraries like cURL, Guzzle, or language‑specific CalDAV clients.

Deployment & Infrastructure

• Self‑Hosting Requirements: A Linux/Unix host with PHP 5 and PostgreSQL. The README explicitly advises against Windows deployments, citing stability concerns.
• Scalability: While the application is single‑process and stateless, scaling can be achieved by running multiple PHP workers behind a load balancer (e.g., HAProxy) and sharing the same PostgreSQL instance.
• Containerization: The project does not ship official Docker images, but the minimal stack makes it trivial to containerize. A typical Dockerfile would expose port 80, mount a volume for the PostgreSQL data directory, and run php-fpm.
• Backup & Recovery: Since all state lives in PostgreSQL, standard database backup tools (pg_dump) suffice. The server itself has no filesystem‑level state beyond configuration files.

Integration & Extensibility

• Plugin System: Developers can add PHP modules that hook into event lifecycle callbacks. The plugin directory is scanned at runtime, allowing dynamic feature addition without altering core files.
• Webhooks: While not built‑in, the hook system can be leveraged to emit HTTP callbacks after event creation or deletion.
• Customization: Themes and client‑side scripts can be swapped by editing the HTML templates in templates/.
• APIs for External Systems: For tighter integration, developers can expose a thin wrapper around the CalDAV endpoints, translating them into RESTful calls or embedding DAViCal in a larger application via sub‑domains.

Developer Experience

• Documentation: The README and wiki provide installation steps, configuration options, and a brief API overview. However, the documentation is terse; developers often need to read source code or consult community forums for advanced topics.
• Community Support: The project is hosted on GitLab, with issue tracking and a small but active mailing list. Contributions are accepted via merge requests, though the codebase is relatively unmaintained compared to newer projects.
• Configuration: Settings are stored in a single PHP file (config.php), making it easy to modify database credentials, ACL defaults, or enable debugging.
• Testing: No automated test suite is shipped; developers rely on manual testing or third‑party CalDAV clients to validate behavior.

Use Cases

1. Enterprise Calendar Service – Organizations can deploy DAViCal on their internal network to provide a unified calendar backend for diverse clients (desktop, mobile, web).
2. Personal Self‑Hosting – Hobbyists who want full control over their calendar data can run DAViCal on a Raspberry Pi or home server.
3. Integration Layer – Developers building custom scheduling tools can embed DAVi