From c8c4095299f5878f76131d2b081ec677a9f24ea4 Mon Sep 17 00:00:00 2001 From: marc Date: Sat, 12 Sep 2026 13:50:37 +0200 Subject: [PATCH] docs: IDEAS.md angelegt; Abo-Link und Aufgabenansicht vertagt Beide haben einen guten Grund, aber keinen Anlass -- und eine Funktion ohne Anlass zu bauen ist der Weg, auf dem eine Anwendung unuebersichtlich wird. Die Ueberlegungen stehen samt dem, was daran nicht trivial ist, in IDEAS.md statt verloren zu gehen. Beim Abo-Link sind das drei Dinge: nur lesend ohne Ausnahme; ein Schalter "nur Belegt/Frei", weil ein Abo sonst jeden Termintitel mitgibt; und dass ein Abo regelmaessig von einer Maschine abgerufen wird -- Zaehler und Fehlversuchssperre der Datei-Freigabelinks passen darauf nicht. Dazu ein Widerspruch, der beim Nachsehen auffiel: "Kalender in der HoneyOS-Leiste" steht seit dem ersten Entwurf in Phase 4, aber HoneyOS hat sich am 29.08.2026 ausdruecklich gegen Widgets entschieden, die Daten aus Aether oder InkNote holen. Der technische Grund dafuer ist inzwischen weg (gleiche Domain), der inhaltliche nicht. Das gehoert entschieden, nicht gebaut -- deshalb im Plan vermerkt statt umgesetzt. Co-Authored-By: Claude Opus 5 --- IDEAS.md | 71 ++++++++++++++++++++++++++++++++++++++++++++++++ kalender-plan.md | 29 ++++++++++++++++++-- 2 files changed, 98 insertions(+), 2 deletions(-) create mode 100644 IDEAS.md diff --git a/IDEAS.md b/IDEAS.md new file mode 100644 index 0000000..dfe5f71 --- /dev/null +++ b/IDEAS.md @@ -0,0 +1,71 @@ +# Ideen + +Was noch kommen könnte. **Nichts davon ist beschlossen** — beschlossen ist, +was im [README](README.md) und in den Plänen steht +([cloud-projekt-plan.md](cloud-projekt-plan.md), [kalender-plan.md](kalender-plan.md)). + +Hier landet, was einen guten Grund hat, aber gerade keinen Anlass. Der +Unterschied ist wichtig: Eine Funktion ohne Anlass zu bauen ist der Weg, auf +dem eine Anwendung unübersichtlich wird. + +--- + +## Kalender + +### Öffentlicher Abo-Link — vertagt (12.09.2026) + +Ein Nur-Lese-Link auf einen Kalender, den jemand **ohne Konto** abonnieren +kann. Nicht dasselbe wie die Freigabe an ein Konto (die steht seit dem +12.09.2026): Dort ist der Empfänger bekannt, hier ist er es nicht. + +**Warum vertagt:** kein Anlass. Marc ist der einzige Nutzer seiner Cloud, und +für den eigenen Gebrauch gibt es bereits zwei Wege an dieselben Termine — die +Weboberfläche und CalDAV mit App-Passwort. + +**Wofür es gut wäre, wenn der Anlass kommt:** + +* Den eigenen Kalender in einer *fremden* Anwendung einblenden, die kein + CalDAV mit Anmeldung kann, sondern nur eine `.ics`-Adresse frisst — etwa + ein Kalender auf der Arbeit. +* Einen Terminplan an Familie oder Verein geben, ohne für jeden ein Konto + anzulegen. + +**Wie es gebaut würde** (damit die Überlegung nicht verloren geht): + +Aether hat die Freigabelinks für Dateien schon, samt Token, optionalem +Passwort, Ablaufdatum und dem Zähler. Ein Kalender-Abo ist dieselbe Sache mit +einer anderen Ausgabe: `GET /share/kalender/{token}.ics` liefert den Export, +den es schon gibt (`api.go`, `Export`). + +Drei Dinge wären dabei zu entscheiden, und sie sind der eigentliche Inhalt: + +1. **Nur lesend, ohne Ausnahme.** Ein schreibbarer Link wäre ein Konto ohne + Passwort. +2. **Was steht drin?** Ein Abo zeigt Titel, Ort und Beschreibung jedes + Termins. Wer „Arzttermin, Dr. Müller" im Kalender stehen hat und den Link + weitergibt, gibt das mit weiter. Ein Schalter „nur Belegt/Frei" (Titel + durch „Belegt" ersetzen) wäre deshalb kein Zierrat, sondern der Grund, + warum man den Link überhaupt zu teilen wagt. +3. **Ein Abo wird regelmäßig abgerufen**, nicht einmal. Ein Kalenderprogramm + fragt alle paar Minuten nach. Der Zähler der Freigabelinks zählte dann + Maschinen statt Menschen, und die Sperre nach zehn Fehlversuchen träfe + einen Client, der bloß ein falsch gespeichertes Passwort wiederholt. + Beides müsste für diesen Linktyp anders sein. + +### Aufgabenansicht (VTODO) — vertagt (12.09.2026) + +Aether nimmt Aufgaben bereits an, speichert sie und gleicht sie ab; die Spalte +`component` in `cal_objects` unterscheidet sie von Terminen. Es fehlt **nur** +die Ansicht in der Weboberfläche. + +**Warum vertagt:** Auf Marcs Telefon gibt es nichts, was sie zeigen würde. +Android hat von Haus aus keinen Speicher für Aufgaben; DAVx5 kann +Aufgabenlisten nur abgleichen, wenn `tasks.org`, OpenTasks oder jtx Board +installiert ist. **Samsungs „Erinnerungen" gehört nicht dazu** — die hängt am +Samsung-Konto, nicht an CalDAV, und wird Aether-Aufgaben nie sehen. + +Eine Ansicht in Aether wäre heute also eine reine Weboberflächen-Aufgabenliste. +Das ist ein eigenes Vorhaben, kein Nebenprodukt des Kalenders. + +**Der Anlass wäre:** Marc probiert `tasks.org` aus und benutzt es. Dann ist die +Ansicht einen Nachmittag Arbeit, und der Unterbau steht schon. diff --git a/kalender-plan.md b/kalender-plan.md index 30e7edb..7efb57d 100644 --- a/kalender-plan.md +++ b/kalender-plan.md @@ -86,7 +86,7 @@ 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. | ✅ | | **2** | Mehrere Kalender, Farbe, Umbenennen, Löschen. Export als `.ics`, Import einer bestehenden Datei. | ✅ | | **3** | Weboberfläche in Aether: Monat, Woche, Liste; Termin anlegen, ändern, löschen. Der Teil, der Spaß macht – und dessen Fehler man **sieht**. | ✅ | -| **4** | `sync-collection` ✅, Teilen mit anderen Nutzern ✅, Aufgabenansicht (vertagt), öffentlicher Abo-Link, Kalender in der HoneyOS-Leiste. | läuft | +| **4** | `sync-collection` ✅, Teilen mit anderen Nutzern ✅. Aufgabenansicht und Abo-Link vertagt → [IDEAS.md](IDEAS.md). Kalender in der HoneyOS-Leiste: **widerspricht einer Entscheidung in HoneyOS**, siehe unten. | im Wesentlichen erledigt | | **5** | Kontakte (CardDAV). Dieselbe Maschinerie, dieselbe Bibliothek – und **einfacher**, weil es dort keine Wiederholungen gibt. | später entscheiden | Über die Phasen hinaus dazugekommen, weil es sich beim Prüfen als nötig @@ -193,12 +193,37 @@ Fall, auf den es ankommt: *ohne Änderung kommt nichts zurück*. vorher nichts sieht – ohne diesen Anfang beweist der Rest nichts. 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.** + Aether hat die Freigabelinks schon. **Vertagt am 12.09.2026** – kein Anlass, + solange es nur ein Konto gibt. Die Überlegung samt der drei Dinge, die daran + nicht trivial sind, steht in [IDEAS.md](IDEAS.md). 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. +## Kalender in der HoneyOS-Leiste – steht im Widerspruch + +Der Punkt steht seit dem ersten Entwurf in Phase 4. Beim Nachsehen am +12.09.2026 stellte sich heraus: **HoneyOS hat sich am 29.08.2026 dagegen +entschieden.** In `honey-os/IDEAS.md`, Abschnitt „Bewusst nicht geplant": + +> **Keine Widgets, die Daten aus Aether oder InkNote holen** (gestrichen +> 29.08.2026). […] der Weg über den HoneyBar-Proxy zeigt HoneyOS in den Apps, +> statt die Apps in HoneyOS nachzubauen. + +Dazu die Grenze, die dort gezogen wurde: *„Nichts, was in einer App lebt, darf +hier ein zweites Zuhause bekommen."* + +Zwei Pläne, zwei Richtungen – das gehört entschieden, nicht gebaut. Zur +Vollständigkeit, was sich seither geändert hat: Der **technische** Grund ist +weg. Seit dem 29.08.2026 liegen Aether und HoneyOS unter derselben Domain, die +Sitzung wird also mitgeschickt; die Leiste läuft ohnehin *in* Aethers Seite und +könnte den Kalender dort gleichursprünglich abfragen, ohne CORS und ohne einen +zweiten Schlüssel. Übrig bleibt der **inhaltliche** Grund, und der ist der +eigentliche: Soll der Schreibtisch Inhalte der Apps zeigen oder nicht? + +Solange das offen ist, bleibt der Punkt hier stehen und wird nicht gebaut. + ## Felder – was ein Termin mitbringt Alles aus RFC 5545, und wir müssen dafür nichts „unterstützen": Wir speichern