Bedankt voor de aanmoediging!
Snelle status: Ik draai momenteel drie instanties van mijn Python ICS→Discourse importer (Uni-lesrooster, Sports Centre-boekingen en een Outlook-agenda). Ik begon het in te pakken als een Discourse-plugin, maar de pluginversie voldeed niet aan de functionaliteit van het script — voornamelijk omdat elke feed specifieke afhandeling nodig heeft (UID-eigenaardigheden, gedeeltelijke updates, annuleringen, ruisende revisies, enz.). Angus’ plugin is geweldig voor veel gevallen; mijn gebruiksscenario’s lijken meer “feed-specifiek”.
Ik heb ook een openstaande PR tegen de kern die gericht is op het verminderen van de ruis van de blauwe knop “Latest” tijdens grote/plotselinge ICS-updates. Bij drukke feeds (zoals universitaire lesroosters) kan een batch met bewerkingen van lage waarde “Latest” laten stuiteren; de PR schakelt effectief de knop “New Topics” uit wanneer Latest open heeft gestaan terwijl een geautomatiseerde batch draait. Ik kan die PR hier graag cross-linken als dat nuttig is.
Lange termijn: Ik draai momenteel op zelf-gehoste IONOS. Als ik later naar officiële hosting ga, zou ik nog steeds graag een manier willen hebben om de Python-flow (of een equivalent) te behouden zonder Enterprise-functies nodig te hebben, als ICS inbound daar bestaat. Ik vermoed dat een generieke kern/plugin-oplossing zou kunnen werken als het plugbare “adapters” per feed toestaat, terwijl sterke idempotentie (ICS UID), annuleringafhandeling en bewerken-zonder-bump-semantiek behouden blijven.
Als er interesse is, kan ik een minimale adapter-interface schetsen en een migratiepad van mijn Python-script naar een Ruby-taak, of feed-agnostische onderdelen (UID-mapping, debounce/no-bump-updates, annuleringslogica) bijdragen aan de kalender/evenementen-plugin.