@Falco هل من الممكن إضافة فحص عام في إعدادات الموقع/المُخْرِج (serializer) لمعرفة ما إذا كان LiveKit مُهيّأ، إلى جانب voice_enabled؟
اليوم، voice_enabled مُعرَض للعميل (client)، لكن لا يوجد إشارة عامة لمعرفة ما إذا كان الموقع قادراً على تقديم خدمات LiveKit. الوصفة الوحيدة المرتبطة بـ LiveKit في الموقع، voice_livekit_per_room_available، مرتبطة بخانة اختيار نموذج الغرفة، لذا تُرجع false عند استخدام سياسة all_rooms، ولا يمكن استخدامها للإجابة على سؤال «هل هذا الموقع يدعم LiveKit على الإطلاق؟».
غالباً ما تغطي RoomSerializer#expected_transport حالة كل غرفة بشكل جيد، لكن ذلك يتطلب جلب الغرف أولاً، وتعود فارغة عندما تكون voice_public_access معطلة، حتى في موقع يكون فيه LiveKit مُهيّأ بالكامل.
هل يكون ما يلي مقبولاً؟ إنه مشتق من الحالة الحالية، ولا يُعرَض أي بيانات اعتماد أو تفاصيل سياسة، ولا يتطلب أي نقطة نهاية (endpoint) جديدة.
سيُضاف في plugins/voice/plugin.rb، بعد كتلة voice_livekit_per_room_available وقبل سطر Voice::DefaultRoomSeeder.ensure! مباشرة:
# إشارة عامة، خالية من بيانات الاعتماد، تُظهر أن الموقع يمكنه تقديم خدمات LiveKit على الإطلاق. add_to_serializer(:site, :voice_livekit_available) do Voice::Livekit.configured? && SiteSetting.voice_livekit_room_policy != "disabled" end
لا يمكن الوصول إلى voice_enabled من واجهة برمجة التطبيقات (JSON API) إطلاقًا: لا يحتوي المسار /site.json على مفتاح site_settings. لذا فإن الإشارة العامة الوحيدة على أن ميزة الصوت تعمل على الموقع هي وجود voice_assets_path.
ما أطالب به هو متغيران منطقيان (booleans) عامان لا يتطلبان بيانات اعتماد، ليتمكن العميل من تحديد ما إذا كان يجب عرض ميزة الصوت قبل جلب أي غرف. كلاهما مشتق من الحالة الحالية ولا يتطلب أي نقطة نهاية (endpoint) جديدة، في الملف plugins/voice/plugin.rb:
في السطر 141، فوق voice_public_access:
#إشارات عامة لا تتطلب بيانات اعتماد لعملاء API تؤكد تمكين الصوت.
add_to_serializer(:site, :voice_available) { SiteSetting.voice_enabled }
في السطر 152، فوق voice_livekit_per_room_available:
# ما إذا كان بإمكان الانضمام استخدام LiveKit على الإطلاق. مجرد نعم/لا: لا يوجد عنوان URL، مفتاح أو
# قيمة سياسة. خاصية كل غرفة أدناه تتحكم فقط في مربع اختيار SFU في نموذج الغرفة،
# وتعود بقيمة false تحت سياسة all_rooms.
add_to_serializer(:site, :voice_livekit_available) do
Voice::Livekit.configured? && SiteSetting.voice_livekit_room_policy != "disabled"
end
هذا لا يكشف عن أي شيء جديد: expected_transport هو خاصية غير مقيدة في RoomSerializer (السطر 30، معرّفة في السطر 150) ويتجاوز rooms#index تسجيل الدخول (rooms_controller.rb:18)، لذا فإن قيم “livekit” / “mesh” قابلة للقراءة بشكل مجهول لكل غرفة بالفعل. هذا يجيب على السؤال دون الحاجة لجلب غرفة قد تعود فارغة.
يرجى عدم ذكر أعضاء الفريق بهذه الطريقة الجماعية (لقد قمت بحذف الأسماء المذكورة).
قد يكون من المفيد أن تصف هدفك النهائي من طلب هذه المعلومات الإضافية. فمن الصعب الإجابة على طلب ميزة جديدة دون تقديم مبرر لكيفية استخدامك لهذه المعلومات.
أعتذر لأنني طرحتُ سؤالًا في إعلان، فتم تحويلي إلى الدعم، مما جعلني غير متأكد من الجهة التي يجب أن أتواصل معها، نظرًا لأن هذا طلب ميزة وليس استكشافًا للأعطال. بعد مراجعة استمرت 5 ساعات، قمت بوسم الأعضاء المشاركين في عمليات الدمج الأساسية (commit/merge) الخاصة بالميزة الصوتية.
ومع ذلك، لإضافة بعض السياق: لدي تطبيق يعمل كمُتصفّح متعدد لمجتمعات Discourse، حيث يتم تكوين كل منها بشكل مختلف، لذا عند الإقلاع يبني التطبيق شريط التنقل الخاص بالموقع الذي يتواجد عليه المستخدم. تظهر ميزة المحادثة إذا كانت مفعّلة، وأود أن تظهر الميزة الصوتية إذا كانت مفعّلة وقابلة للانضمام فعليًا من التطبيق.
ينضم التطبيق عبر LiveKit ولا يمكنه استخدام تقنية الشبكة (mesh)، لذا في المواقع التي تستخدم تقنية mesh، أريد استبعاد الميزة الصوتية من شريط التنقل تمامًا، بدلاً من عرض غرف ستفشل في الاتصال، مما يجعل الأمر يبدو وكأن التطبيق معطوب.
لذا، سير العمل هو: قراءة معلومات الموقع مرة واحدة عند الإقلاع، ثم تحديد ما إذا كانت الميزة الصوتية تنتمي إلى التطبيق في ذلك الموقع، ثم استخدام expected_transport لكل غرفة عندما يفتحها المستخدم. المتغيران الشرطان (booleans) هما مجرد الخطوة الأولى، وبدونهما سأعرض إما ميزة لا يمكن أن تعمل، أو أخفي ميزة يمكن أن تعمل.
بديلًا لذلك، يمكنني وضع رسالة “غير متاحة في هذا المنتدى” في تنبيه عام داخل التطبيق بغض النظر عن كونها مفعّلة أم لا، لكن هذا بدا لي نهجًا أفضل، لذا حددتُ نقطة الدخول وقدمت الكود والتعليقات.
إضافة الصوت جديدة وتوجد في مرحلة تجريبية. من المرجح أن تخضع لتغييرات في الأسابيع والأشهر القادمة، خاصة التغييرات الداخلية. نحن منفتحون على إتاحة هذه المعلومات بطريقة ما، لكن لا يمكننا الجزم بعد بالشكل الذي ستأخذه. يعتمد الأمر على كيفية تطور تكامل LiveKit.
أعتقد أنك فهمتني بشكل خاطئ، كنت مستيقظًا من الساعة 1 صباحًا حتى 5 صباحًا لمراجعة ما تم إنجازه والدمجات (Merges)، وبهذا طرقت على أعضاء الفريق الذين حددتهم في البداية. وليس الأمر أنني أنتظر ردًا لمدة 5 ساعات. التطبيق تم إرساله بالفعل للمراجعة، وهو يستخدم النظام الافتراضي الذي أملكه بالفعل.
هذا مقبول بالنسبة لي، خذ الوقت الذي تحتاجه. لقد أجريت اختبارات على مدى فترة 6 أشهر، واستغرق الأمر بعض الضبط الدقيق للتوسع.