diff --git a/kalender-plan.md b/kalender-plan.md index 5a32b64..3a1137d 100644 --- a/kalender-plan.md +++ b/kalender-plan.md @@ -4,6 +4,20 @@ Stand 02.09.2026. Ausgangspunkt: Radicale ist für einen einfachen selbst gehosteten Kalender überraschend umständlich (Konfigurationsdateien, dünne Doku, keine OIDC-Anbindung). +## Festgelegt (02.09.2026) + +- **Mehrere Kalender** von Anfang an. Nicht weil es heute drei sein müssen, + sondern weil es jetzt eine Spalte ist und später ein Umbau. +- **Aufgaben (VTODO)** werden von Anfang an gespeichert und über CalDAV + angeboten; die Ansicht in Aether kommt später. Muss vorher feststehen, weil + jeder Kalender dem Client meldet, was er kann – nachträglich richten die + Clients ihre Konten neu ein. +- **Ändern statt neu erzeugen**, sobald unsere eigene Oberfläche schreibt. +- Anhänge sind kein Ziel. Falls doch, dann als Verweis in Aethers Dateien – + nie als eingebettete Datei in der `.ics`. +- Erinnerungen weckt die App auf dem Telefon. Browser-Benachrichtigungen in + der Weboberfläche: nett für später, kein Drang. + ## Entscheidung: ein Modul in Aether, kein eigener Dienst Der Grund ist genau das, was bei Radicale gefehlt hat. @@ -72,15 +86,67 @@ Die abgeleiteten Spalten sind nur zum Vorsortieren da. | **1** | CalDAV lesend und schreibend, ein Kalender, Anmeldung über App-Passwörter, Auffindpfade (`/.well-known/caldav`, `current-user-principal`, `calendar-home-set`). Ziel: DAVx5 gleicht ab. | 1–2 Abende | | **2** | Mehrere Kalender, Farbe, Umbenennen, Löschen. Export als `.ics`, Import einer bestehenden Datei. | 1 Abend | | **3** | Weboberfläche in Aether: Monat, Woche, Liste; Termin anlegen, ändern, löschen. Der Teil, der Spaß macht – und dessen Fehler man **sieht**. | 2–3 Abende | -| **4** | `sync-collection` statt Vollabgleich, Aufgaben (VTODO), Kalender in der HoneyOS-Leiste. | offen | +| **4** | `sync-collection` statt Vollabgleich, Aufgabenansicht, Teilen mit anderen Nutzern, öffentlicher Abo-Link, Kalender in der HoneyOS-Leiste. | offen | | **5** | Kontakte (CardDAV). Dieselbe Maschinerie, dieselbe Bibliothek – und **einfacher**, weil es dort keine Wiederholungen gibt. | später entscheiden | -## Was es ausdrücklich nicht wird +## Teilen – drei Bedeutungen, zwei davon gehen -Keine Einladungen an andere Leute (iMIP/Scheduling), keine Frei/Belegt-Abfragen -über Häuser hinweg, kein Teilen zwischen Nutzern. Das ist der Teil, an dem -Groupware-Server groß und kompliziert werden. Ein Kalender für dich, auf allen -deinen Geräten – das ist das Ziel. +„Geteilter Kalender" meint je nach Person etwas anderes: + +1. **Derselbe Kalender auf mehreren Geräten.** Das ist der Sinn der Sache und + ab Phase 1 da. +2. **Ein Kalender, den ein anderer Nutzer sieht** – lesend oder schreibend, wie + das Teilen in Nextcloud. Geht, und es ist keine Protokollarbeit: Wir kennen + unsere Nutzer und unsere Kalender, also ist es eine Tabelle + (`kalender × nutzer × recht`) und eine Bedingung in `ListCalendars`. Der + Client sieht danach schlicht einen Kalender mehr in seiner Liste. **Phase 4.** +3. **Ein Kalender an der Adresse eines Links**, den jemand ohne Konto + abonnieren kann – nur lesend, wie ein Freigabelink für Dateien. Klein, und + Aether hat die Freigabelinks schon. **Phase 4.** + +Was **nicht** kommt: Einladungen per E-Mail (iMIP/iTIP) und Frei/Belegt-Abfragen +über Serviergrenzen hinweg. Das ist der Teil, an dem Groupware groß und +kompliziert wird – und der einzige, der wirklich wehtut. + +## Felder – was ein Termin mitbringt + +Alles aus RFC 5545, und wir müssen dafür nichts „unterstützen": Wir speichern +die Datei unverändert, also überleben auch Felder, die wir nicht kennen. + + RRULE/EXDATE Wiederholung · DESCRIPTION Notiz · LOCATION Ort + VALARM Erinnerung · CATEGORIES · CLASS privat/öffentlich + ATTENDEE Teilnehmer (gespeichert, aber niemand wird eingeladen) + DTSTART ohne Uhrzeit = ganztägig + +**Die Regel, die Daten rettet:** Sobald unsere Oberfläche einen Termin ändert, +wird die vorhandene Datei eingelesen, die angefassten Felder ersetzt und der +Rest unberührt zurückgeschrieben. Nie neu erzeugen. Sonst verschiebt man am +Rechner einen Termin um eine Stunde und die Erinnerung, die das Telefon +angelegt hatte, ist weg – und das fällt erst Wochen später auf. + +## Clients, gegen die geprüft wird + +| Client | Prüft | +|---|---| +| **DAVx5 → Samsung Kalender** | der Hauptweg. DAVx5 schreibt in Androids Kalenderspeicher, Samsung Kalender liest daraus. In der App unter „Kalender verwalten" einmal sichtbar schalten, und DAVx5 von der Akkuoptimierung ausnehmen. | +| **Tasks.org** | Aufgaben. Androids Kalenderspeicher kennt keine – ohne so eine App bietet DAVx5 die Aufgabenlisten gar nicht erst an, und **Samsung Kalender zeigt sie nie**. | +| **Thunderbird** | der gutmütige Prüfstein am Rechner, Termine und Aufgaben nebeneinander. | +| **Vivaldi** | Marcs Browser bringt einen CalDAV-Kalender mit. Wie eigenwillig er ist, wissen wir noch nicht. | +| **HoneyOS** | braucht **kein** CalDAV: Kachel und Leiste fragen Aethers eigene JSON-Schnittstelle. CalDAV ist für fremde Programme. | + +## Standards und Vorbild + + RFC 5545 das .ics-Format + RFC 4791 CalDAV (PUT, REPORT, calendar-query) + RFC 6764 /.well-known/caldav – damit reicht dem Client der Hostname + RFC 5397 current-user-principal: „wer bin ich, wo liegen meine Kalender" + RFC 6578 sync-collection: nur Änderungen holen + RFC 6352 CardDAV, falls Kontakte dazukommen + +Wo der Standard Spielraum lässt, halten wir es wie **SabreDAV**: Nextcloud und +Baïkal stehen beide darauf, das ist also das Verhalten, an das die Clients +gewöhnt sind. Radicale ist zum Nachlesen gut – kurzer Code –, aber es ist nicht +die Fassung, gegen die getestet wurde. ## Die Notausfahrt