ICS → مستورد Discourse عبر واجهة برمجة تطبيقات REST

شكرًا على التنبيه!

ملخص سريع: أقوم حاليًا بتشغيل ثلاث نسخ من برنامج استيراد Python الخاص بي من ICS إلى Discourse (جدول مواعيد الجامعة، حجوزات مركز الرياضة، وتقويم Outlook). بدأت في تغليفه كمكون إضافي لـ Discourse، لكن إصدار المكون الإضافي لم يصل إلى مجموعة ميزات البرنامج النصي - ويرجع ذلك أساسًا إلى أن كل تغذية تحتاج إلى معالجة مخصصة (غرائب معرفات فريدة، تحديثات جزئية، إلغاءات، مراجعات مزعجة، إلخ). المكون الإضافي الخاص بـ Angus رائع للعديد من الحالات؛ حالات الاستخدام الخاصة بي تبدو أكثر “خاصة بالتغذية”.

لدي أيضًا طلب سحب مفتوح ضد النواة يهدف إلى تقليل ضوضاء زر “الأحدث” الأزرق أثناء تحديثات ICS الكبيرة/المتقطعة. مع التغذيات المزدحمة (مثل جداول مواعيد الجامعات)، يمكن لمجموعة من التعديلات ذات القيمة المنخفضة أن تبقي “الأحدث” في حالة اهتزاز؛ يقوم طلب السحب بتنفيذ زر “المواضيع الجديدة” بشكل فعال عندما يكون “الأحدث” مفتوحًا أثناء تشغيل دفعة آلية. يسعدني ربط طلب السحب هذا هنا إذا كان مفيدًا.

على المدى الطويل: أنا حاليًا على IONOS المستضاف ذاتيًا. إذا انتقلت إلى الاستضافة الرسمية لاحقًا، فلا يزال بإمكاني الاستمتاع بطريقة للحفاظ على تدفق Python (أو ما يعادله) دون الحاجة إلى ميزات Enterprise، إذا كان ICS الوارد موجودًا هناك. أشك في أن حلاً عامًا للنواة/المكون الإضافي يمكن أن يعمل إذا سمح بـ “محولات” قابلة للتوصيل لكل تغذية مع الحفاظ على التماثل القوي (معرف فريد لـ ICS)، ومعالجة الإلغاء، ودلالات التعديل بدون رفع.

إذا كان هناك اهتمام، يمكنني رسم واجهة محول بسيطة ومسار ترحيل من برنامج Python النصي الخاص بي إلى مهمة Ruby، أو المساهمة بقطع مستقلة عن التغذية (تعيين معرف فريد، إلغاء الضوضاء/التحديثات بدون رفع، منطق الإلغاء) في المكون الإضافي للتقويم/الأحداث.

إعجاب واحد (1)