Das ist eine gute Frage, Nathan – und ich denke, es gibt definitiv Raum für einen minimalen, Feed-unabhängigen Ansatz, der entweder als kleine Erweiterung des Calendar/Event-Plugins oder als leichtgewichtiger Core-Job existieren könnte.
Damit ein PR allgemein nützlich ist, scheint der Schlüssel darin zu liegen, den Importeur adapterbasiert und nicht Feed-spezifisch zu gestalten. Etwas wie:
- Jeder Feed definiert einen kleinen Adapter (kann Python, YAML oder Ruby sein), der ICS-Felder → Discourse-Topic-Felder (
title,body,tags,start,end,locationusw.) abbildet. - Core kümmert sich um Idempotenz (
UID↔ Topic-ID-Mapping), Stornierungen (STATUS:CANCELLED) und stille Bearbeitungen (Update ohne Bumpen von Latest). - Plugins oder Site-Einstellungen könnten das Abfrageintervall, Tag-Mappings und die Bump-Richtlinie (
always,never,on major change) konfigurieren.
Auf diese Weise können Institutionen mit verrauschten oder komplexen Feeds (Universitätsstundenpläne, Raumbuchungen, Outlook-Kalender usw.) einen Adapter bereitstellen, der auf ihre Daten zugeschnitten ist, ohne etwas im Core fest zu codieren.
Wenn Interesse besteht, würde ich gerne diese Adapter-Schnittstelle skizzieren oder den Core “ICS upsert”-Helfer als Ruby-Job prototypisieren, auf dem andere aufbauen können – damit sich dies schrittweise von eigenständigen Python-Skripten zu etwas Wartbarem und Generischem innerhalb des Discourse-Ökosystems entwickeln kann.