Danke für den Anstoß!
Kurzer Status: Ich führe derzeit drei Instanzen meines Python ICS→Discourse-Importers aus (Uni-Stundenplan, Sportzentrum-Buchungen und einen Outlook-Kalender). Ich habe begonnen, ihn als Discourse-Plugin zu verpacken, aber die Plugin-Version blieb hinter dem Funktionsumfang des Skripts zurück – hauptsächlich, weil jeder Feed eine individuelle Behandlung benötigt (UID-Eigenheiten, Teilaktualisungen, Stornierungen, viele Revisionen usw.). Angus’ Plugin ist für viele Fälle großartig; meine Anwendungsfälle scheinen eher „Feed-spezifisch“ zu sein.
Ich habe auch einen offenen PR gegen den Kern, der darauf abzielt, das Rauschen des blauen „Latest“-Buttons bei großen/burstigen ICS-Updates zu reduzieren. Bei stark frequentierten Feeds (wie Universitätsstundenplänen) kann eine Charge von geringwertigen Bearbeitungen den „Latest“-Button ständig aufpoppen lassen; der PR deaktiviert effektiv den „New Topics“-Button, wenn „Latest“ geöffnet war, während eine automatisierte Charge läuft. Gerne verlinke ich diesen PR hier, wenn er nützlich ist.
Langfristig: Ich bin derzeit auf selbst gehostetem IONOS. Wenn ich später zu einem offiziellen Hosting wechsle, würde ich mir immer noch wünschen, den Python-Flow (oder ein Äquivalent) beibehalten zu können, ohne Enterprise-Funktionen zu benötigen, falls ICS-Inbound dort existiert. Ich vermute, eine generische Kern-/Plugin-Lösung könnte funktionieren, wenn sie austauschbare „Adapter“ pro Feed zulässt und gleichzeitig eine starke Idempotenz (ICS-UID), Stornierungsbehandlung und Bearbeitung-ohne-Bump-Semantik beibehält.
Wenn Interesse besteht, kann ich eine minimale Adapter-Schnittstelle und einen Migrationspfad von meinem Python-Skript zu einem Ruby-Job skizzieren oder Feed-unabhängige Teile (UID-Mapping, Debounce/No-Bump-Updates, Stornierungslogik) zum Kalender-/Event-Plugin beitragen.