C’est une bonne question, Nathan — et je pense qu’il y a définitivement de la place pour une approche minimale et indépendante du flux qui pourrait exister soit comme une petite extension du plugin Calendar/Event, soit comme une tâche légère au cœur du système.
Pour qu’une PR soit généralement utile, la clé semble être de rendre l’importateur basé sur des adaptateurs plutôt que spécifique au flux. Quelque chose comme :
- Chaque flux définit un petit adaptateur (qui pourrait être en Python, YAML ou Ruby) qui mappe les champs ICS → champs de sujet Discourse (
title,body,tags,start,end,location, etc.). - Le cœur gère l’idempotence (mappage
UID↔ ID de sujet), les annulations (STATUS:CANCELLED), et les modifications silencieuses (mise à jour sans faire remonter le dernier). - Les plugins ou les paramètres du site pourraient configurer l’intervalle d’interrogation, les mappages de tags et la politique de remontée (
always,never,on major change).
De cette façon, les institutions ayant des flux bruyants ou complexes (horaires universitaires, réservations de salles, calendriers Outlook, etc.) peuvent fournir un adaptateur adapté à leurs données sans coder en dur quoi que ce soit dans le cœur du système.
S’il y a de l’intérêt, je serais heureux de décrire cette interface d’adaptateur ou de prototyper l’aide principale “ICS upsert” sous forme de tâche Ruby sur laquelle d’autres pourront s’appuyer — afin que cela puisse évoluer progressivement des scripts Python autonomes vers quelque chose de maintenable et de générique au sein de l’écosystème de Discourse.