All Classes and Interfaces
Class
Description
Outcome of probing a CalDAV account server-side, before anything is stored:
a stable code the connect drawer translates — the same codes the browser
probe historically produced, so the drawer's messages did not change when
the probe moved behind the platform (where BlueMind's missing CORS headers
stop mattering).
What the relay answers the browser with: the upstream server's status and
body — DAV logic like 207 multistatus parsing or the 412 conflict discipline
lives in the caller, so statuses pass through untouched — under a
response-header allow-list, with advertised hrefs rewritten into relay space
and the credential-related statuses already translated (an upstream 401
means the stored CalDAV credentials are stale, never that the eXo
user is unauthenticated, so it must not travel as a 401).
One DAV request the browser asks the platform to relay to a declared CalDAV
server.
A CalDAV server registration, as an administrator declared it: where the
server lives and how it is presented to users.
A calendar pair as the service layer handles it.
The lifecycle of one calendar pair.
One calendar object's identity across the two sides, as the service layer
handles it.
Which side of the pair created the collection, and therefore which side owns
its existence.