هذا سؤال جيد يا ناثان - وأعتقد أن هناك بالتأكيد مجالًا لنهج بسيط وغير مرتبط بالخلاصة يمكن أن يعيش إما كتوسيع صغير لمكون الإضافي للتقويم/الحدث أو كوظيفة أساسية خفيفة الوزن.
لكي يكون طلب السحب مفيدًا بشكل عام، يبدو أن المفتاح هو جعل المستورد قائمًا على المحول بدلاً من كونه خاصًا بالخلاصة. شيء مثل:
- تحدد كل خلاصة محولًا صغيرًا (يمكن أن يكون بايثون أو YAML أو روبي) يقوم بتعيين حقول ICS → حقول موضوع Discourse (
title،body،tags،start،end،location، إلخ). - تتعامل الوظيفة الأساسية مع التكرار (تعيين
UID↔ معرف الموضوع)، والإلغاء (STATUS:CANCELLED)، والتعديلات الهادئة (التحديث دون تخطي الأحدث). - يمكن للمكونات الإضافية أو إعدادات الموقع تكوين فترة الاستطلاع، وتعيينات العلامات، وسياسة التخطي (
always،never،on major change).
بهذه الطريقة، يمكن للمؤسسات ذات الخلاصات الصاخبة أو المعقدة (جداول الجامعات، حجوزات الغرف، تقويمات Outlook، إلخ) توفير محول مناسب لبياناتها دون ترميز أي شيء بشكل ثابت في الوظيفة الأساسية.
إذا كان هناك اهتمام، فسأكون سعيدًا بتحديد واجهة المحول هذه أو إنشاء نموذج أولي لمساعد “ICS upsert” الأساسي كوظيفة روبي يمكن للآخرين البناء عليها - حتى يتطور هذا تدريجيًا من نصوص بايثون مستقلة إلى شيء قابل للصيانة وعام ضمن نظام Discourse البيئي.