Uses of Package
org.exoplatform.caldav.client

  • Class
    Description
    One access control entry of a collection's DAV:acl, as RFC 3744 §5.5 defines it: who it applies to, whether it grants or denies, which privileges, and whether the server lets it be changed (EXO-90253).
    Whom an entry applies to: one of the six forms RFC 3744 §5.5.1 allows.
    The forms of DAV:principal.
    What the server answered to an ACL request (EXO-90253): a claim, never a fact.
    The CalDAV protocol, and nothing else: it fetches, it does not decide.
    Where a CalDAV conversation is allowed to go: the scheme and authority of one administrator-declared server, plus the account's base collection path on it.
    The one failure the CalDAV client throws for protocol and transport trouble: the server unreachable, an answer outside the accepted statuses of the verb, a body that is not DAV XML, or a target this client refuses to address.
    The CalDAV door: every write is the CalDavClient method of the same name, with the same headers, the same body and the same answer.
    One calendar collection as a PROPFIND listed it: everything the sync engine binds a pair on, and nothing it does not need.
    What one discovery walk answers: who the authenticated user is on the server, and where that user's calendars live.
    One calendar object (an .ics resource) as the server answered it.
    The door through which one calendar object is written to, or removed from, a server — the four write shapes the engine uses, and nothing else.
    Picks the door a server's copies go through: the one write-channel decision of the whole engine (EXO-90307).
    A collection's DAV:acl as the server answered it to its owner (EXO-90253), with the two facts that decide whether it may be written back.
    What a resource says it supports, as CalDavClient.capabilities(org.exoplatform.caldav.client.CalDavEndpoint, java.lang.String) gathers it: the compliance classes of its DAV header (RFC 4918 §10.1) and the methods of its Allow header (RFC 9110 §10.2.1) — the two pieces of evidence the sharing capability is selected from (EXO-90253).
    What an MKCALENDAR answered — deliberately never a boolean "created".
    What the server answered to a PROPPATCH — the raw status and the statuses of every propstat that did not grant its property.
    What a conditional PUT answered.
    Which incremental-sync tier a collection's server can serve, read from one Depth:0 PROPFIND (supported-report-set, ctag, sync token) plus the DAV response header.
    The incremental strategies of the plan, cheapest first.
    How a calendar server lets an owner grant somebody else access to a collection, and whether eXo offers it there (EXO-90253).
    What an RFC 6578 sync-collection REPORT answered: the hrefs that changed, the hrefs that are gone, and the token to store for the next run.
  • Class
    Description
    The CalDAV protocol, and nothing else: it fetches, it does not decide.
    Where a CalDAV conversation is allowed to go: the scheme and authority of one administrator-declared server, plus the account's base collection path on it.
    The one failure the CalDAV client throws for protocol and transport trouble: the server unreachable, an answer outside the accepted statuses of the verb, a body that is not DAV XML, or a target this client refuses to address.
    The calendar server authenticated a session as somebody other than the account eXo asked for, and nothing was sent in it.
    The door through which one calendar object is written to, or removed from, a server — the four write shapes the engine uses, and nothing else.
    What a resource says it supports, as CalDavClient.capabilities(org.exoplatform.caldav.client.CalDavEndpoint, java.lang.String) gathers it: the compliance classes of its DAV header (RFC 4918 §10.1) and the methods of its Allow header (RFC 9110 §10.2.1) — the two pieces of evidence the sharing capability is selected from (EXO-90253).
    What a conditional PUT answered.
    How a calendar server lets an owner grant somebody else access to a collection, and whether eXo offers it there (EXO-90253).
  • Class
    Description
    Where a CalDAV conversation is allowed to go: the scheme and authority of one administrator-declared server, plus the account's base collection path on it.
    The door through which one calendar object is written to, or removed from, a server — the four write shapes the engine uses, and nothing else.
    What a resource says it supports, as CalDavClient.capabilities(org.exoplatform.caldav.client.CalDavEndpoint, java.lang.String) gathers it: the compliance classes of its DAV header (RFC 4918 §10.1) and the methods of its Allow header (RFC 9110 §10.2.1) — the two pieces of evidence the sharing capability is selected from (EXO-90253).
    How a calendar server lets an owner grant somebody else access to a collection, and whether eXo offers it there (EXO-90253).
  • Class
    Description
    The CalDAV protocol, and nothing else: it fetches, it does not decide.
    Where a CalDAV conversation is allowed to go: the scheme and authority of one administrator-declared server, plus the account's base collection path on it.
    One calendar collection as a PROPFIND listed it: everything the sync engine binds a pair on, and nothing it does not need.
    What a resource says it supports, as CalDavClient.capabilities(org.exoplatform.caldav.client.CalDavEndpoint, java.lang.String) gathers it: the compliance classes of its DAV header (RFC 4918 §10.1) and the methods of its Allow header (RFC 9110 §10.2.1) — the two pieces of evidence the sharing capability is selected from (EXO-90253).
    How a calendar server lets an owner grant somebody else access to a collection, and whether eXo offers it there (EXO-90253).
  • Class
    Description
    Where a CalDAV conversation is allowed to go: the scheme and authority of one administrator-declared server, plus the account's base collection path on it.