Der Zentralkalender soll eine Webplattform sein, in der Gruppen rund um Freie Software ihre Veranstaltungen planen können. Entgegen der Namensgebung wird hier über ein dezentralisiertes System nachgedacht, das den Austausch und die gesammelte Darstellung von Terminen ermöglicht.

Der Name der Software ist DisCal

Anforderungen

Einfache Einbindung: Der Kalender kann einfach in bestehende Webseiten eingebunden werden, dies gilt für die gesamte Vielfalt von Webseiten, wie sie bei LUGs anzutreffen ist
Keine Anbieterbindung: eine Gruppe muss sich keiner zentralen Instanz unterwerfen, um das System zu betreiben (kein Facebook für LUGs)
Der Kalender ist nicht regional beschränkt
Individualisierung: Jeder Benutzende kann sich eigene Views erstellen, die Termine in der eigenen Umgebung anzeigen.
Es können sowohl regelmäßige, als auch einmalige Termine eingetragen werden.

Umsetzung dieser Anforderungen

Das System exportiert und importiert Termine in verschiedenen Formaten, darunter auch fertig gebaute HTML-Ansichten, die via iFrame/HTML-include eingebunden werden können (einfache Einbindung)
Mehrer Parallelimplementieungen in verschidenen Programmiersprachen sind denkbar (einfache Einbindung)
Das System ist hochverteilt, ein zentraler Server ist nicht notwendig (keine Anbieterbindung)
Installationen stehen nicht zwingend miteinander in Verbindung, jeder Betreiber entscheidet
selbst, mit wlchen Gruppen sein seine Installation Termine austauscht, z.B. mit [http://en.wikipedia.org/wiki/Webhook webhooks] (Übersichtlichkeit ohne Regionalisierung, "Spam"schutz, Individualisierung)
Jede Gruppe kann das System selbst hosten, hat aber auch die Möglichkeit einen externen Anbieter zu nutzen

Begriffsklärung

Schwestersysteme sind Installationen, die untereinander Termine austauschen, z.B. befreundete LUGs, die ihre Termine gegenseitig auf ihren Webseiten anzeigen
Kollektorsystem eine Installation, die Termine von anderen Gruppen anzeigt, bzw. exportiertorganisiert.
Induktorsystem eine Installation, von der eine Termineintragung im Netzwerk ausgeht

Schritte bei der Realisierung

Quellcoderepository klar machen
vServer/(Sub)domain klar machen (In-Berlin?)
- vServer wird von BeLug gestellt (Lutz), Domain: opensource-events.org
  - UPDATE DONE: Registrierung beim IN-Berlin erledigt, DNS registriert, vserver eingerichtet (Lutz)
Proof of Concept: von paul bis 27.9.2010
Woche vom 27.9: Treffen zwischen Paul und Ivan wg. Zusammenarbeit mit GriCal

Technische Umsetzungen

personalisierte Views/Exportviews ohne Benutzeraccount möglich (z.B. über URL-Codierung, vgl. doodle)
Eintragen von Terminen nur mit Benutzeraccount
- bei einem Hochverteilten System sollte dies vom Hoster entschieden werden
Registrieren von Schwestersystemen: dito
Schwestersysteme können durch Polling miteinander verbunden werden
- Beispiel: eine Kalenderinstalation liest die iCal-Daten von einer anderen Website
Schwestersysteme können durch Push-Frontends verbunden werden
- Beispiel: bei Termineintragungen/-änderungen publiziewrt das Induktorsystem die Änderung über einen Webservice der vom Kollektorsystem bereitgestellt wird
- Eine Authentifizierung ist ggf. notwendig
Kollisionserkennung auf Kollektorseite wird nötig sein, um identische Termine zu erkenne, die schon über mehrere Schwestersysteme publiziert wurden

Aufbau

Eine Site Besteht aus:

Event store
- zum Lesen und Schreiben des Stores werden standard Import- und Exportmodule verwendet
Config
Site registry
- Sites, an die gepushed wird
- Sites, von denen gepolled wird
Importmodule
- iCal
Exportmodule
- iCal
- RSS
- HTML-Body (HTML-Page ist ein Frontend)
Frontends
- HTML-Page
- Ausgabe für beliebige unterstützte Exportformate
- Editieren der Config (edit-config)
- Eventeingabe (enter-event)
- Registrierung von Schwesterseiten (push-register)

Mögliche Benutzerrollen

Admin, darf:
- Config editieren
User, darf:
- Termine eintragen
- je nach Konfiguration
  - Schwesterseiten in die Site-Registry eintragen
  - Schwesterseiten bestätigen
  - Terminänderungen bestätigen
Empfehlung: in der Praxis sollten kleinere Sites keine Rollentrennung durchführen (nur Admin-Konten vergeben)

Datenformat

Das generische Austauschformat ist iCalendar, DisCal erweitert das Format um folgende Atribute (Atribute von VEVENT):

X-HOP: ein ganzzahliger Wert, der mit jeder Weiterpublizierung inkrementiert wird
X-REVISION: ein ganzzahliger Wert, der mit jeder Änderung am Event inkrementiert wird
X-REVISE-URL: die URL zu einem Frontend, an dem eine Änderung des Events registriert wird, idR. beim Induktorsystem

Verknüpfen einer Site mit einer anderen

Via Polling:

In der Site Registry auf Site B wird Site A für polling registriert
über ein Importmodul werden regelmäßig Daten von dieser Site in den lokalen Event store übertragen
- ist das Atribut X-HOP leer oder ungültig, wird es auf 1 gesetzt, ansonsten um 1 inkrementiert
- ist das Atribut X-REVISION leer oder ungültig, wird es auf 1 gesetzt, ansonsten übernommen
- ist das Atribut X-REVISE-URL leer, wird die URL zum revise-frontend von Site B eingetragen
- ist die UID leer (sollte bei iCal-Quellen nicht vorkommen) oder liegt in einem nicht iCal-Konformen Format vor, wird eine UID mit dem FQDN von Site A im Domain-Part generiert

Via Pushing:

Eine Site B ruft an Site A das Frontend push-register auf, um mitzuteilen, dass sie über Events informiert werden will
- Site B stellt entweder Credentials für Site A zur verfügung
- oder lädt einen GPG-Public-Key von Site A herunter
Site A nimmt die Registrierung an (automatisch, oder nach Admin/User-Bestätigung)
An Site A wird ein Termin eingetragen (via enter-event)
- Die Eingabemaske für Termine überträgt keine UID und kein Atribut X-HOP, X-REVISION oder X-REVISE-URL
- sind alle Atribute leer, werden sie generiert
  - eine UID für das Event
  - Das Atribut X-HOP wird auf 0 gesetzt
  - Das Atribut X-REVISION wird auf 0 gesetzt
  - Das Atribut X-REVISE-URL wird auf die URL des Revise-Frontends von Site A gesetzt
- sind alle Atribute im gültigen Wertebereich, werden sie übernommen
- sind alle oder einige Atribute ungültig (oder nur einige leer), wird der Eintrag ignoriert
Site A speichert den Termin im lokalen Event Store
gleichzeitig: Site A sieht in der Site Registry, dass ein Push an Site B durchgeführt werden soll
Site A ruft das Frontend enter-event von Site B auf
- Site A überträgt den Termin entweder GPG-Signiert
- oder unter Nutzung der Credentials
- Dieser Termin enthält bereits eine UID
- Das Atribut X-Hop wird inkrementiert
Site B übernimmt den Eintrag in den lokalen Event Store wenn:
- ein Event mit gleicher UID noch nicht existiert
- ein Event mit gleicher UID in einer geringeren Revision vorliegt (das Event wird dann überschrieben)
Site B ignoriert den Eintrag wenn:
- Ein Event mit gleicher UID schon in gleicher oder höherer Revision existiert
Site B ignoriert den Eintrag auf Basis von Kriterien, de der Admin festlegt, z.B.:
- Die Geo-Koordinaten des Events sind zu entfernt
- Bestimmte Tags treffen nicht zu
- X-HOP ist zu hoch
Site B führt ihrerseits push-Operationen an Seiten aus der eigenen Site-Registry durch

Publizieren von Eventänderungen

Szenario: Modifikation beim Ursprung

Ein Benutzer auf Site A legt ein Event an
Das Event wird im Netzwerk publiziert
Ein Benutzer ändert das Event an Site A
- Die UID wird beibehalten
- Das Atribut DTSTAMP wird auf die aktuelle Zeit gesetzt (DisCal ignoriert dieses Atribut, der iCal-Standard schreibt eine Erneuerung jedoch vor)
- Die Atribut X-REVISION wird inkrementiert
- Das neue Event wird publiziert

Szenario: Modifikation auf anderer Seite

Ein Benutzer auf Site A legt ein Event an
Der Termin wird im Netzwerk publiziert
Ein Benutzer ändert das Event an Site B
- Die UID wird beibehalten
- Das Atribut DTSTAMP wird auf die aktuelle Zeit gesetzt
- Die Atribut X-REVISION wird inkrementiert
- Das neue Event wird publiziert
- Das neue Event wird an X-REVISE-URL (ans Site A) gemeldet
Site A nimmt die Änderung an (automatisch, oder nach Admin/User-Bestätigung)
- Ist das Atribut X-REVISION kleiner, oder gleich der Revision, die aus sich von A aktuell ist, so wird die Revision zurückgehalten und ein Admin oder User wird informiert um den Konflikt aufzulösen
- Bei der Konfliktauflösung wird die Revisionsnummer weiter inkrementiert
Das geänderte Event wird durch A publiziert (siehe obige Beschreibung)

Existierende Projekte

GriCal
- python / django
- Wiki
- Repository: mercurial
- Code und HTML getrennt
- Export: ical, rss
- Einspeisung: via Email, webinterface
- mehrsprachig
- nicht LUG-gebunden
- Themenzuordnungen
- Gruppenzuordnung
- Features/wanted Features: private Veranstaltungen, email-notification, selbstgeklickte Formate
Drupal als Framework
- Calendar Date Modul Test
  - work in progress, soon at nerdcafe dot 10247 dot net
  - Dynamischer Austausch von Daten via ICal und RSS integriert
  - Einfach, neue Views zu erstellen
Webcalendar
- hmm.. sorry, das ist zwar ein Groupware-Kalender, hat aber mit den aufgeführten anforderungen nichts zu tun
- keine Austauschdynamik zwischen verschiedenen Installationen
  - Synchronisation mit anderen Kalendersystemen, nur durch upload/download über das Webinterface,
  - keine Zeitgesteuerte Synchronisation gegen andere Sites
- Augenmerk auf Funktionalität, die wir gar nicht brauchen
  - z.B. Abbildung einer Firmenhierarchie (Chef muss/kann Termine Bestätigen, etc)
  - Abstufung von öffentlichen/internen/geheimen Terminen
- Code Check
  - keine Globals
  - (fast) keine Templates, PHP mit HTML gemixt
  - keine Plugin-Architektur
  - wenig Code-Doku
  - von 2005, aber immer noch ~aktiv~ (ein paar neue AJAX Funktionen und Bugfixes)

Frage : Warum nennt man dann die Seite nicht Discal wie das gleichnamige Programm ? Ich zumindest würde, wenn ich eine solche Software suche nie auf die Idee kommen "Zentralkalender" suchen zu lassen...Und ich glaube ich bin da nicht der einzige der sich da einen Kopf über den unpassenden Namen macht.