Dav Laravel Package

Technical Evaluation

Architecture fit

• sabre/dav is a standalone, event-driven DAV server framework: a Server object owns routing, HTTP method handling, XML (PROPFIND/REPORT) parsing, and the auth/lock layers; plugins extend behavior; a Tree + node/backend abstraction isolates storage. This is a framework, not a Laravel package — there is no service provider, facade, config file, or artisan command.
• Fit for a Laravel product is therefore "library inside the app," not "package in the app." Expect to write and own a thin adapter (~1–2 weeks of senior PHP effort for a first vertical slice) that boots Sabre\DAV\Server inside a Laravel route group.
• The main architectural seam is HTTP. sabre ships its own sabre/http request/response objects; Laravel ships Symfony HTTP Foundation. You must convert inbound requests and stream DAV bodies back without Laravel rewriting, buffering, or decorating them.
• Auth is a second seam. sabre's auth backends (Basic, PDO, IMAP) do not know about Laravel guards, Sanctum, or session cookies. You will implement a custom BackendInterface that resolves to your users/principals model.
• Storage is a third seam and the biggest design decision: use sabre's PDO/FS backends against a separate schema, or implement custom Collection/File nodes backed by Eloquent. The custom-node path gives you tenancy and auditability at the cost of performance engineering.

Integration feasibility

• Technically feasible and well-trodden: Nextcloud and ownCloud are built on this lineage, so the "Laravel app + sabre/dav" pattern is proven even without a packaged Laravel bridge.
• Dependency weight is low and clean (sabre/xml, sabre/http, sabre/event, sabre/uri, sabre/vobject, PSR-3 log). Composer install is trivial; the effort is entirely in the adapter and domain modeling.
• Key unknowns to validate in a spike: streaming PROPFIND through Laravel's middleware stack, avoiding CSRF/session middleware on the DAV route group, and correct Content-Length/chunked handling for large PUTs.

Technical risk

• Vendor concentration. Development is driven by fruux, with commercial support available. That is a plus (paid escalation path) but a risk (single-vendor roadmap).
• Release cadence is slow and pragmatic. 4.x has been maintained since 2019; 4.7.0 (Oct 2024) added PHP 8.4 fixes. That is stable-but-quiet, not fast-moving — plan for security patching on your own schedule rather than upstream urgency.
• Metadata integrity. The supplied signals conflict: "Stars: 4," "Dependents: 0," and "opportunity: 55.25" against a package widely described as the de facto PHP WebDAV framework with 1.7k+ stars. Treat the score (9.38) as unverified until the source data is corrected; do not present these figures to stakeholders as-is.
• Protocol surface is deep. CalDAV scheduling (iTIP/iMIP), sync-tokens, lock semantics, and time-range filtering are subtle. Bugs here surface as silent client-side sync failures in Apple Calendar/Outlook, not as 500s.
• Beta-era residue. The 4.0.0 line went through alpha/beta in 2018–2019; the 4.2.3 revert (#1365) shows BC discipline is taken seriously, which lowers upgrade risk but also means features you want may stall.
• Testing gap. You need litmus (WebDAV) and CalDAV/CardDAV client conformance testing in CI; these are not shipped as part of your Laravel test suite.

Key questions

1. Which protocol do we actually need first — WebDAV file sync, CalDAV scheduling, or CardDAV — and does the first release need writes or is read-only sufficient?
2. Do we need scheduling (invites, free-busy) and email delivery (iMIP), or only storage and sync?
3. What is the principal model — must DAV principals map 1:1 to Laravel users/tenants, and how is cross-tenant isolation enforced?
4. Is there appetite to own a custom backend, or do we accept sabre's PDO schema as a second source of truth?
5. What is the fallback if upstream stalls: fork, commercial support contract, or accept a frozen dependency?
6. Who on the team has RFC 4918/4791/6352 experience, and what is the bus factor?

Integration Approach

Stack fit

• Laravel is a good host: it gives you routing, queues, Eloquent, policies, and observability around a library that expects only PSR-7-ish requests and responses. PHP 8.1–8.4 on Laravel 10/11 aligns with 4.7.0's supported range (PHP 7.1–8.4).
• Deliver as an internal Composer package (e.g., acme/laravel-dav) rather than inline code: one service provider, one config file, one route registration, one auth backend, one storage backend. This keeps the third-party surface auditable and swappable.
• Do not attempt to route DAV through Laravel's normal controller/response pipeline. Terminate the request into sabre and let it write the response, or convert its response faithfully at the boundary.

Migration path

• There is no data to migrate on day one — this is greenfield protocol exposure over existing domain data (files, events, contacts). The migration question is really a schema question: whether existing Eloquent tables become the DAV source of truth (custom nodes) or are projected into sabre's PDO tables (sync jobs, dual-write risk).
• Preferred: custom Collection/File/CalendarObject nodes backed by existing models, with a repository layer. This avoids a second database schema and keeps tenancy in one place.
• Fallback if timeline is tight: sabre's PDO backend on a dedicated connection, with the existing models treated as the system of record and a projection layer added later — accept this only as an explicitly temporary, flagged decision.

Compatibility

• Pin sabre/dav to a caret range on the 4.x line and lock it in composer.lock; track upstream 4.x patch releases only.
• Watch transitive constraints: sabre/vobject for iCalendar/vCard correctness (timezone handling is the usual bug source), and psr/log v2/v3 compatibility already resolved upstream in 4.2.2.
• Client compatibility matrix must be explicit and tested: Apple Calendar/iOS, Outlook (CalDAV via add-in or WebDAV), Thunderbird, DAVx5, Nextcloud, Windows Explorer/macOS Finder for WebDAV. Each fails differently.
• Exclude the DAV route group from: CSRF, session start, Authenticate redirect-to-login, response encryption/transform middleware, and any global output buffering or compression that breaks streaming.

Sequencing

1. Spike (1–2 weeks). Mount sabre behind a catch-all route, wire a custom Basic auth backend to Laravel users, serve a read-only SimpleCollection. Prove streaming and auth. Exit criteria: a real client (DAVx5 or macOS Finder) mounts and lists.
2. Auth and principals (1 week). Principal model, per-tenant rooting, ACLs, rate limiting, request logging.
3. Single write path (2–3 weeks). One node type with PUT/GET/DELETE, transactional writes, and litmus in CI.
4. Second protocol (3–4 weeks). CalDAV or CardDAV with sync-tokens; conformance tests against two real clients per platform.
5. Scheduling / hardening (as needed). iMIP, locks, quotas, observability dashboards, load test at target concurrency.
6. Ship behind a feature flag, DAV-only hostname or path prefix, with a documented kill switch.

Operational Impact

Maintenance

• Budget ~10–15% of one engineer's time steady-state: upstream patch review, client-compatibility regression testing on OS/browser releases, and log triage.
• Upstream cadence is roughly a couple of minor releases per year with sporadic patch releases; the PHP-version support window (currently through 8.4) is the main forcing function for upgrades. Treat PHP upgrades as coupled work: Laravel major + sabre minor in the same cycle.
• The adapter is your code and your bug surface. Every upstream upgrade requires re-running the litmus and client conformance suites, not just unit tests.

Support

• Community support is via GitHub issues and the sabre.io docs; there is a commercial escalation path through fruux. Decide now whether to contract support or designate an internal owner with DAV expertise.
• Because this is BSD-3-Clause, there is no vendor lock-in on the code — but there is practical lock-in on the protocol semantics your clients have come to expect.

Scaling

• The stateless parts (PROPFIND, GET, PUT) scale like any PHP-FPM workload; the constraints are large-collection PROPFIND (use depth-limited and paginated queries, stream results) and large file PUTs (bypass PHP memory limits with streamed writes; consider offloading blob storage).
• Locks and sync-tokens are stateful and must live in shared storage (Redis/DB), never local filesystem. On multi-node deployments, sabre's FS lock backend is a correctness bug waiting to happen.
• CalDAV/CardDAV read amplification is real: sync reports and time-range queries need indexes on principal, collection, and lastmodified/etag. Existing release notes call out SQLite index additions and PDO sync fixes — evidence this is a known hot spot.
• Add per-principal rate limits and request-size caps at the edge; DAV clients retry aggressively and can thundering-herd a cold cache.

Failure modes

• Silent sync divergence. Client believes it is current; server has stale or mis-ordered sync-tokens. Symptom: missing or duplicated events, no error. Detect with periodic token/etag consistency checks and client-side smoke tests in CI.
• Partial writes without locks. Concurrent PUTs on the same resource cause lost updates or corrupted calendar objects. Enforce locking or last-writer-wins semantics explicitly, per protocol.
• Auth/session bleed. DAV requests accidentally hitting session or CSRF middleware produce 419s or redirects that clients report as "cannot connect," not as auth errors. Hard-fail fast on the DAV route group instead.
• Streaming breakage. Middleware buffering or gzip on PROPFIND/PUT manifests as truncated files or timeouts — worst case, silent data loss on large uploads. Assert Content-Length and checksums server-side.
• Timeout-driven inconsistency on long-running collection moves/deletes; make operations idempotent and retryable.
• iMIP/scheduling mail failures are invisible to the calendar client; queue them and expose delivery status.
• Metadata/upstream abandonment. Low bus factor upstream; if releases stop, you inherit patching. Mitigate by keeping the adapter thin enough to replace the engine.

Ramp-up

• Realistic curve: a senior PHP engineer with no DAV background needs 2–3 weeks to be productive inside sabre's event/plugin model, and 1–2 months to be trusted with CalDAV scheduling and sync semantics. WebDAV file sync alone is the shallow end.
• Required reading: RFC 4918 (WebDAV), 4791 (CalDAV), 6352 (CardDAV), plus sabre.io's plugin and backend docs. Budget for this explicitly — it is the dominant cost, not the code.
• Onboarding artifacts to produce: the adapter's request-lifecycle diagram, a client compatibility matrix with pass/fail per client version, a runbook for "client won't sync," and a litmus/conformance test guide.
• Pair the DAV work with whoever owns auth and tenancy; most integration incidents are auth/ACL boundary mistakes, not protocol bugs.

TPM recommendation

• Proceed with a time-boxed spike and treat adoption as a conditional buy: high confidence on protocol coverage and license, medium confidence on the Laravel integration boundary, and low confidence in the supplied metadata — correct the star/dependent/opportunity figures before this reaches a steering deck. Gate the full commitment on the spike proving streaming, auth bridging, and one real client mounting successfully.