تطبيق الدردشة: PubSubhubbub مقابل XMPP

Question

لست متأكدًا من أفضل مكدس لإنشاء تطبيق دردشة. حاليا أفكر في خيارين رئيسيين:

• Tornado Facebook
  • سلبيات: لا تستخدم بروتوكول الدردشة الرئيسي XMPP ولكن PubSubhubbub
  • الايجابيات: أنا حقًا أحب بساطتها من أجل التنمية (WebServer + Webframework) ؛ يبدو PubSubhubbub أبسط أيضًا كبروتوكول من XMPP ؛ وأنا أعرف بيثون
• XMPP + Bosch ، البنجاب ، Ejabberd
  • السلبيات: لا أعرف إرلانج ؛ بشكل عام يبدو أن التطوير أصعب قليلاً
  • الإيجابيات: يستخدم بروتوكول XMPP

سيحتاج تطبيق الدردشة إلى الحصول على ما يلي:

• رسائل خاصة
• الغرف العامة
• غرف خاصة
• سجل الدردشة للغرف (وليس إلى الأبد ، فقط رسائل N الأخيرة)
• HTML التضمين
• عنوان URL للدردشة

يبدو كلا الخيارين قابلين للتطوير ، لذا فإن هذا ليس قلقًا حقًا (نحن نفكر في تشغيل التطبيق في Amazon's EC2 أيضًا). أعلم أن هناك مشروعًا يبني خادم XMPP باستخدام Tornado ، لكنه ليس جاهزًا لاستخدام الإنتاج وموعد النهائي ليس كبيرًا. في الأساس ، فإن قلقي الرئيسي هو سهولة التطوير مقابل الأسف إلى حد ما في وقت لاحق باستخدام PubSubhubbub لتطوير تطبيق دردشة ، لكنني قرأت في مكان ما أن PubSubhubbub قد يحل محل XMPP في النهاية حيث تم استبدال الصابون - فما رأيك؟

Answer 1

اذهب ل XMPP.

خارج الصندوق ، يتمتع Ejabberd بدعم لجميع متطلباتك. لن تحتاج إلى رؤية أي Erlang وكتابة وحدات مخصصة لـ Ejabberd. ومع Strophejs ، فإن XMPP في المتصفح (وهو ما تفعله على ما يبدو) رائع.

لسؤالك الأخير حول استبدال PubSubHubBub بدل XMPP ، لا تعتمد عليه. XMPP أكثر من 10 سنوات من العمر ، ومفتوح المصدر الصلب والتطبيقات القابلة للتشغيل البيني على حد سواء على العميل والخادم ، وهي أنيقة لذلك لن تختفي.

وأنت تقوم بتطوير تطبيق الدردشة وهو ما تم صنعه XMPP.

Answer 2

Facebook Tornao لا يستخدم PubSubhubbub على الإطلاق!

انتقل إلى XMPP ، تم تصميمه لما تبحث عنه. لم يكن Tornado مصممًا لذلك بشكل خاص ، ولكن لطلبات الاقتراع الطويلة بشكل عام.

لا حاجة لاستخدام البنجاب ، تقوم وحدة Ejabbed HTTP-Bind بعمل جيد جدًا الآن. أيضًا ، لا تحتاج إلى تعلم Erlang ، بنفس الطريقة التي لا تحتاجها إلى تعلم C عند كتابة موقع ويب يستخدم Apache :) تحقق من أشياء مثل أريستوشات. الشيء الوحيد الذي ستحتاج إليه هو تكوين خادم XMPP وغرف الدردشة ، وبعد ذلك ، JavaScript لجانب العميل (في المتصفح).

Answer 3

إذا كنت لا تحتاج إلى اتحاد عبر XMPP ولكنك تريد النموذج الأولي والنشر بسرعة مع قابلية التوسع خارج الصندوق ، ألق نظرة على مثال Web Web Framework خادم الدردشة في صفحة واحدة من التعليمات البرمجية.

Answer 4

لم يكن المقصود من PubSubhubbub (Push) لتطبيقات الدردشة في المقام الأول. يشار إليه أحيانًا باسم "IM for the Web". أود أن أقترح عليك أن تذهب من خلال هذه الشريحة: RUBY Ruby لشبكة RealTime Web بواسطة Igrigorik

السؤال هو حقًا كيف تريد أن تحصل على الوقت الحقيقي؟ إذا كنت تريد السرعة ، فإن XMPP هي الخيار الأفضل. (500 مللي ثانية) بينما يعتمد الدفع على خلاصتك وكيف تم نقله. تذكر ، مع دفع ما مجموعه 4 قفزات الشبكة قبل أن يصل المحتوى إلى المشترك.

المشكلة الأكبر هي تعتمد على Push على Post HTTP. حتى إذا انتهى بك الأمر في تصميم تطبيق دردشة استنادًا إلى Push ، وتقول في مرحلة لاحقة ، فأنت تريد إتاحته للأجهزة الأخرى أو حتى كطبق سطح المكتب ، يجب عليك نقل المحتوى نفسه باستخدام XMPP. المكان الآخر الذي ستخسره هو أنه سيكون من الصعب للغاية على مستخدمي تطبيق الدردشة تسجيل الدخول من أي IM آخر من اختيارهم.

Answer 5

يمكنك استخدام واجهة برمجة تطبيقات REST مع WebSocket لتنفيذ بنية الناشر/المشترك.

الغلاف الجوي و مآخذ التباهي هي إطار Java لطيف يمكنك الإضافات في الخاص بك جيرسي استراحة واجهة برمجة التطبيقات وتحقيق ذلك.

مدونة منشئ Atmospehre ، Jfarcand ، لديها واحدة مثال على تطبيق الدردشة بنيت مع هذه التقنيات.