أنا أخطط لكيفية إضافة دعم ActivityPub إلى العلامات (Tags) بأفضل شكل، أي السماح للعلامات بأن تكون جهات فاعلة في ActivityPub. يحتاج النموذج الذي يدعم ActivityPub إلى تخزين مخصص خاص بالسجل. إحدى الطرق لتحقيق ذلك هي باستخدام حقول مخصصة، على سبيل المثال:
هناك طرق أخرى لتحقيق نفس النتيجة، ولكن الحقول المخصصة ربما تكون الأكثر مباشرة، وستكون الأكثر اتساقًا مع نموذج بيانات كل من إضافة ActivityPub وربما Discourse نفسها.
لذلك، فكرت في قياس مدى الرغبة في إضافة دعم الحقول المخصصة (CustomField) للعلامات (Tags) أولاً، والتي يمكنني تقديم طلب سحب (PR) لها إلى discourse/discourse.
لقد قمت بإنشاء طلب سحب (PR) لهذا. لاحظ أن هذا هو التنفيذ الأساسي الممكن، حيث لا يلزم تسلسل قائمة العلامات، ولا تحرير المعلومات (أي في واجهة مستخدم معلومات العلامة):
أعتقد أن جاذبية الحقول المخصصة تكمن في أنها تتمتع بهيكل تكامل محدد مسبقًا، على سبيل المثال سجل المكونات الإضافية وواجهة برمجة تطبيقات المكونات الإضافية. وجود طريقة مستقرة للتكامل مع نموذج أساسي هو أفضل من إنشاء تكامل مخصص من وجهة نظري.
أنا أفهم ما تقصده بشأن الحقول المخصصة. أعتقد أنني سأقول إن هذه المشكلات موجودة بغض النظر. سواء كانت الحقول المخصصة للعلامات موجودة أم لا، فلن يغير ذلك.
مع مرور الوقت، أصبح العيب في الحقول المخصصة هو أنها مرنة للغاية، ويميل الناس إلى تخزين هياكل معقدة وضخمة في كتلة واحدة.
أتفهم تمامًا أنك تريد نوعًا من الخريطة “الرسمية” لكيفية القيام بذلك.
أعتقد أنني سأعيد السؤال إليك… ما الذي نتحدث عنه بالضبط هنا؟
في كل مرة يعرض فيها discourse علامة، هل يحتاج إلى عرض شيء خاص؟ (هذا وحش لتحسينه لأن هناك العديد من الأماكن التي يتم فيها عرض العلامات)
هل هذه صفحة العلامة فقط؟
هل هذه مجرد مهمة خلفية يقوم المسؤولون بتكوينها؟
أعتقد أننا سنبدأ من هناك؟ ماذا تريد أن تفعل بالضبط؟ ماذا يرى المستخدمون المختلفون؟ إلخ…
سيقومون بتخزين بيانات ActivityPub المرتبطة بعلامة تؤدي دور ممثل ActivityPub. لا أحتاج إلى أي تسلسل لأي أجزاء من العميل في discourse/discourse. لن يرى المستخدم هذه البيانات في أي جزء من عميل discourse/discourse العادي. سيتم تسلسل البيانات إلى عميل المسؤول، جنبًا إلى جنب مع بيانات أخرى، ومع ذلك تتم إدارة ذلك بواسطة المكون الإضافي في مسارات مسؤول المكون الإضافي المخصصة. كما ذكرت، فإن التسلسل في مسارات علامات discourse/discourse الحالية (أو مُسلسل الموقع) سيكون صعبًا، وذلك لأسباب مختلفة وليس شيئًا أرغب في محاولة القيام به، ولهذا السبب لم أضف طرق واجهة برمجة تطبيقات قابلة للتحميل المسبق أو قابلة للتحرير.
بالإضافة إلى وجود واجهة برمجة تطبيقات مستقرة للعمل معها، فإن السبب في تفضيلها في مكون ActivityPub الإضافي هو أن المكون الإضافي يخزن أنشطة ActivityPub في مجموعة منفصلة من نماذج البيانات، وهي جداول discourse_activity_pub_*، والتي تتكامل بعد ذلك مع discourse/discourse عبر واجهات برمجة التطبيقات المحددة للمكون الإضافي والحقول المخصصة للنماذج الأساسية. يوجد بعض التكرار المتعمد هنا لضمان الفصل السليم للاهتمامات بين بيانات Discourse و ActivityPub. نظرًا لأن Discourse و ActivityPub لديهما سلسلة من المفاهيم ونماذج البيانات المترابطة، ولكنها مختلفة، فإن الحفاظ على تمييز واضح بين بيانات ActivityPub وبيانات discourse/discourse ضروري للحفاظ على بعض الوضوح (والعقلانية) في مكون إضافي كبير ومعقد. يعد استخدام الحقول المخصصة كنقطة تكامل مفيدًا جدًا في الحفاظ على هذا الفصل نظيفًا ومستقرًا.
يوجد شرح موجز لهذا في ملف README الخاص بالمكون الإضافي.
أعتذر بشدة عن التأخير هنا يا @angus. هل يمكننا محاولة إضافة دعم العلامات إلى ActivityPub بدون حقول مخصصة للعلامات؟
أعلم أن هذا ليس متسقًا مع نموذج البيانات الذي نستخدمه حاليًا هناك للفئات، ولكنه نهجنا المفضل. إضافة دعم الحقول المخصصة للعلامات في النواة يعني أننا سنفتح الباب للدعم الكامل لها في النواة، وأعلم أن طلبك السحب (PR) لا يضيف هذا، ولكنه سيدفع المطور التالي إلى دفع الباب أكثر قليلاً.
