Merci pour la relance !
État rapide : J’exécute actuellement trois instances de mon importateur Python ICS → Discourse (horaire universitaire, réservations du centre sportif et calendrier Outlook). J’ai commencé à l’intégrer en tant que plugin Discourse, mais la version plugin n’a pas atteint l’ensemble des fonctionnalités du script, principalement parce que chaque flux nécessite une gestion sur mesure (bizarreries d’UID, mises à jour partielles, annulations, révisions bruyantes, etc.). Le plugin d’Angus est excellent dans de nombreux cas ; mes cas d’utilisation semblent plus « spécifiques au flux ».
J’ai également une PR ouverte contre le cœur visant à réduire le bruit du bouton bleu « Latest » lors de mises à jour ICS importantes/soudaines. Avec des flux chargés (comme les horaires universitaires), un lot d’éditions de faible valeur peut faire rebondir « Latest » ; la PR désactive efficacement le bouton « New Topics » lorsque Latest est resté ouvert pendant qu’un lot automatisé s’exécute. Je suis heureux de lier cette PR ici si cela est utile.
À plus long terme : Je suis actuellement sur IONOS auto-hébergé. Si je passe à l’hébergement officiel plus tard, j’aimerais toujours avoir un moyen de conserver le flux Python (ou un équivalent) sans avoir besoin de fonctionnalités Enterprise, si ICS inbound existe là-bas. Je soupçonne qu’une solution générique de cœur/plugin pourrait fonctionner si elle permettait des « adaptateurs » enfichables par flux tout en conservant une forte idempotence (UID ICS), la gestion des annulations et la sémantique d’édition sans rebond.
S’il y a de l’intérêt, je peux esquisser une interface d’adaptateur minimale et un chemin de migration de mon script Python vers un job Ruby, ou contribuer des pièces indépendantes du flux (mappage d’UID, mises à jour de débat/sans rebond, logique d’annulation) au plugin calendrier/événements.