©moonrun, Fotolia.com
Termine außerhalb der eigenen Groupware auszutauschen, ging bislang gar nicht oder nur asynchron. Caldav erledigt das schnell und bequem .
Google, Yahoo, Sun, Apple, Oracle, Microsoft, Lotus: was sich wie das Who-is-Who der IT-Welt anhört, ist nur ein Ausschnitt einer Liste der Firmen, die zuletzt bekannt gaben, in ihren Groupware-Angeboten Caldav [1] oder dessen Varianten Groupdav [2], Carddav [3] einzusetzen.
Aufgeholt
Vor zwei Jahren bemängelte ein Artikel auf Linux-Magazin Online [4], dass nur wenige Server das Format für den Austausch von Kalenderdaten beherrschten. Das hat sich gründlich geändert, vom I-Phone bis zu Linux-Mailservern wie Opengroupware, Kerio (Abbildung 1) und Communigate existiert mittlerweile eine Vielzahl von Tools, die dank Caldav auch mit fremden Groupwareservern planen können, ohne auf Bestätigungsmails der Teilnehmer warten zu müssen.
Abbildung 1: Hersteller wie Kerio wollen mit Ihrem Caldav-Engagement gerade auch die Mac-User anbinden.
Der Erfolg des Standards scheint logisch, auch weil sonst keine andere Techologie in Sicht ist, mit deren Hilfe sich in Echtzeit Termine aushandeln lassen, wenn die Teilnehmer eine fremde Groupware verwenden. Auch die IETF kennt das Problem und hat jüngst in RFC 5545 [5] ein Update der “Internet Calendaring and Scheduling Core Object Specification” herausgebracht. Mit deren Hilfe soll sich gerade im Bereich der Terminplanung einiges verbessern.
Echtzeit Fehlanzeige
Calendaring ist deutlich komplexer, als es den meisten Anwendern bewusst ist. Viele kleinere Systeme, Server und Clients gleichermassen, beherrschen nur die Terminplanung für einen einzelnen Benutzer und scheitern daran, mehrere Kalender in Einklang zu bringen. Bei Verfügbarkeit, Free-/Busy-Listen und Gruppenterminen mit gemeinsam genutzten Ressourcen sträuben sich deshalb Admins und IT-Leitern gleichermassen die Nackenhaare.
In lokalen Teams funktioniert das zwar meist gut, aber zum Beispiel Kolab dazu zu überreden, mit Lotus Notes vom Partnerunternehmen zu kooperieren, erweist sich als unmöglich. Darum verschicken Nutzer freier wie kommerzieller Groupware E-Mails mit Terminanfragen in Formaten wie sie das Icalendar Message-Based Interoperability Protocol (IMIP, [6]) oder das Icalendar Transport-Independent Interoperability Protocol (ITIP, [7]) vorgeben. Erst wenn beide Seiten E-Mails gelesen und den Termin (wieder per Mail) bestätigt haben, ist er in beiden Kalendern eingetragen, die Interaktion vom Benutzer bleibt notwendig.
Caldav-Scheduling
Im Gegensatz zum althergebrachten Versenden von Ical-Anfragen per Mail, lässt sich mit Caldav Scheduling [8] eine standardisierte Echtzeit-Terminplanung zwischen verschiedenen Groupware-Systemen erreichen. Nicht an einen Kalenderserver angebundene Remote-User integriert dabei entweder IMIP oder bald das neue, noch unfertige Internet Scheduling Protocol (Ischedule, [9]).
Das macht es dem Client viel einfacher, weil er die komplexen IMIP- oder ITIP-Protokolle, bei denen meist mehrere Benutzer gleichzeitig auf einem Datensatz arbeiten, nicht mehr selbst implementieren muss. Caldav-Scheduling gestaltet diesen Prozess deutlich stabiler, weil der Server die Konsistenz sicher stellt. Inhaltlich ist es zwar nach wie vor ITIP, aber eben über HTTP und Webdav in Echtzeit anstatt des asynchronen E-Mail-Verfahrens(Kasten “Installation mit Apache”).
| Installation mit Apache |
|---|
Apache reicht als Backend für Caldav, auch ohne das recht experimentelle »mod_ caldav«-Modul. Der Admin schaltet dazu einfach Webdav an (zum Beispiel über Yast), stellt die Authentifizierung ein, und markiert Verzeichnisse als Kalender und Adressbücher, so wie mit diesem Skript [10]:
groupdav-set.sh http://MyWebdavServer/Calendars/helge/ EVENT,VTODO "Helge's Calendar" So erfährt der Client, dass er den Folder »/Calendars/helge/« als Terminkalendar und Todoliste anzeigen soll. |
Der Client, zum Beispiel das Zideone-Outlook-Plugin (Abbildung 2) für Caldav-Server wie Opengroupware, speichert einen Termin einfach via HTTP-Put:
Abbildung 2: Der Outlook-Connector von Zidelook bringt dem Microsoft-Tool Caldav und Groupdav bei.
BEGIN:VEVENT SUMMARY:Meeting ATTENDEE;PARTSTAT=ACCEPTED:hh@zideone.de ATTENDEE;PARTSTAT=TENTATIVE:nat@zideone.de ATTENDEE;PARTSTAT=TENTATIVE:bigboss@ibm.com DTSTART;TZID="Europe/Berlin":20090921 (...) END:VEVENT
Jetzt schaut der Server nach, ob Teilnehmer auf seinem System beheimatet sind. Trifft dies zu, dann bindet er die Meeting-Anfrage direkt und in Echtzeit in den Kalender des Teilnehmers ein. Der kann den Termin annehmen oder ablehnen, der Server verteilt auch diese Info wiederum automatisch an alle lokalen User. Kennt er den externen Teilnehmer nicht, dann verschickt er wie bisher IMIP-Mails an andere Teilnehmer und sammelt die Antworten selbstständig ein. Spricht der andere Server ebenfalls Caldav, dann lassen sich Termine über Groupware-Grenzen vereinbaren.
XMPP-Push
Ein vor allem für mobile Anwender interessantes Caldav-Feature, das bisher nur Apple in seinem Ical-Server und der Ical-Applikation implementiert, ist XMPP-Push [10]. Das von Jabber bekannte Extensible Messaging and Presence Protocol [11] ist in den RFCs 3920 bis 3923 [12] spezifiziert und definiert den Standard, über den ein Server seinen Client über Änderungen informiert. XMPPP-Pubsub (Publish and Subscribe, [13]) ermöglicht es Anwendern, Informationen zu veröffentlichen (Publish) und den Abonnenten (Subscribers) kurze Infos zukommen zu lassen, dass es Updates gibt.
Apple hat diesen Standard auf Webdav erweitert, um dem Client das ständige Nachfragen (Poll) nach Änderungen zu ersparen. Jetzt sagt der Server der Anwendung, dass es etwas Neues gibt. An sich ist XMPP-Push natürlich nicht auf Caldav beschränkt, jeder Webdav-Client kann es benutzen. Für XMPP-Pubsub gibt es zahlreiche Bibliotheken, die die Implementierung einfach machen.
Webdav-Sync
Webdav selbst ist stateless. Möchte ein Client erfahren, was sich auf dem Server geändert hat, dann muss er selbst alle Verzeichnisse durchgehen und nachschauen, bei welchen Datensätzen sich das so genannte Entity-Tag [14] geändert hat. Gerade bei großen Kalendern ab etwa 1000 Einträgen ist das recht aufwändig und für mobile Geräten kostspielig. Vor allem wenn er kein XMPP-Push verwendet, triggert der Mailclient in der Regel diese Aktion alle paar Minuten.
Anders läuft das mit Webdav-Sync [15], wie das Sun, Oracle, Apple und die Enterpriseversion von Opengroupware, Scalable Ogo (Sogo) bereits implementieren. Hier gibt der Server bei einem »ls« auch ein »sync«-Tag zurück, das der Client bei der nächsten Anfrage einbindet und so nur Infos über die Datensätze erhält, die Benutzer seit dem letzten Mal neu angelegt, geändert oder gelöscht haben. Die Antwort ist deutlich kleiner, der Abgleich um einiges schneller.
Overhead
Der Preis dafür ist der Overhead auf dem Server, denn der muss sich merken, wer wann was gelöscht hat. Auch Webdav-Sync ist nicht auf Caldav beschränkt, sondern steht prinzipiell allen Webdav-Anwendungen zur Verfügung, vor allem Admins von Servern, wo Anwender viele Dateien gemeinsam nutzen, dürften daran Freude haben.
Jede Menge Software
Die jüngste Entwicklung von Caldav scheint vielversprechend. Vor allem Apple, Oracle und Sun treiben es voran. Deshalb wundert es nicht, dass Apples Ical- oder Darwin-Cal-Server, Oracles Beehive (der Nachfolger der Oracle Collaboration Suite) und Suns Aries das universelle Austauschprotokoll unterstützen. Auch Sogo beherrscht es teilweise.
Als Clients kommen Apples Ical (Abbildung 1), der I-phone-Kalender (Abbil- dung 3), Mozilla Lightning und Microsoft Outlook mit den richtigen Addons und Plugins infrage. Als eher experimentell gelten Emclient (Payware für Windows), Evolution, Mulberry und Suns Caldav-Erweiterung für Symbian-Telefone. KDE Kontact kann nur etwas Groupdav der alten Version 1, und selbst das hat wohl nie so richtig zuverlässig funktioniert (Abbildung 4). Hier bleibt die Hoffnung, dass der Akonadi-Rewrite auch ein besseres Caldav-Hroupdav-Backend beschert.
Abbildung 3: Mobiles Caldav mit dem I-Pod Touch: Caldav ist neben Google und Yahoo eine der von Apple standardmäßig in die aktuelle Firmware eingebauten Kalender-Varianten.
Abbildung 4: Kontact unterstützt leider nur Groupdav Version 1, und selbst das nur rudimentär.
Die Liste ist damit noch nicht zu Ende, einige andere Server bieten ebenfalls Caldav-Support, wenn auch von unterschiedlicher Qualität: Scalix, Zimbra, der Chandler-Server, eGroupware, Kerio, Apache mit Mod_caldav, Opengroupware, Citadel (nur Groupdav Version 1), Mail Enable und Ice Warp. Wem das nicht reicht, der wird bei Google und Yahoo (Zimbra) fündig. Eine wichtige Motivation hinter diesem Engagement ist sicherlich die Kommunikation mit Apples Endgeräten und Desktops. Aber so lange die beteiligten Unternehmen dabei offene Standards fördern, kann das dem Admin von Linux- Groupware nur recht sein.
