\documentclass{article}
\usepackage{ulem}
\pagestyle{headings}
\begin{document}
\part{ CalDAV\footnote{http://example.com/index.php?page=CalDAV} workflows for Kronolith}
\section{ Create/Update (davPutObject)}
- rpc determines this is a dav request\newline
- delegates to RPC dav backend\newline
- Feeds into Sabre\\Dav\\Server\newline
- SabreDAV\footnote{http://example.com/index.php?page=SabreDAV} stores the event to its calendar backend\newline
- horde/dav Calendar backend internally finds out the caldav name of the calendar is served by kronolith\newline
- Kronolith\_Application::davPutObject is called.\newline
- Resolve external calendar name to kronolith-internal calendar name\newline
- Perform some access checks\newline
- Parse icalendar data string into a Horde\_Icalendar object\newline
- Setup the Horde\_Icalendar\_Handler\_Dav with the calendar backend and the icalendar

Kronolith\_Icalendar\_Dav (inherits Kronolith\_Icalendar\_Base)\newline
- Get all components of the calendar\newline
- ignore everything which is not a VEVENT\newline
- try to load an existing kronolith event\newline
- check if existing event last modified is newer / abort\newline
- keep a list of exception events from the VEVENT for later\newline
- Create a list of organizer and attendee(s) who signal by attribute that it's not the server's job to send them itip mails\newline
- Create the new kronolith\_Event base event object from the icalendar vevent\newline
- Delete all kronolith\_events which are exceptions on the base event from the backend\newline
run the post-save actions for the base event\newline
- check for missing mapping between external and internal event id, add if missing\newline
- handle decision-making on itip: Is the change relevant for itip (prevent spam). Who should get an itip? which type of itip to send out?

back in the main process\newline
- create an kronolith\_event for each previously listed vevent exceptions and save it

\section{ TODOs/Refactoring}
TODO: Factor out the iTip handling into a separate service which just takes previous and current event and possibly some intent control\newline
TODO: Make this flow unit testable (How?)\newline
TODO: Make the iTip flow reusable for web UI and inter-app API cases.

\section{ Ajax saveEvent vs the davPutObject flow}
- UI has a different data/attribute format\newline
- more context or intent can be communicated ("as new", "send updates/no updates", "move event to different calendar"\newline
- more specific permission checks\newline
- Add event can check for a limit\newline
- edit event can check for edit permissions\newline
- very similar itip related code

\end{document}
