2010-03-18 12 views
7

No estoy seguro de la mejor pila para construir una aplicación de chat. Actualmente estoy pensando en dos opciones principales:aplicación de chat: pubsubhubbub vs xmpp

  • facebook tornado
    • contras: no utiliza el protocolo XMPP principal de chat, pero pubsubhubbub
    • pros: me gusta mucho su sencillez para el desarrollo (servidor web + marco web); pubsubhubbub también parece más simple como protocolo que xmpp; y sé pitón
  • xmpp + Bosch, Punjab, ejabberd
    • contras: no saben Erlang; en general parece un poco más difícil de desarrollar
    • pros: utiliza el protocolo XMPP

La aplicación de chat tendrá que tener lo siguiente:

  • mensajes privados
  • habitaciones Públicas
  • Habitaciones privadas
  • Historial de chat de habitaciones (no para siempre, solo los últimos n mensajes)
  • HTML que incorpora
  • url para sala de chat

Ambas opciones parecen escalable de modo que en realidad no es mi preocupación (estamos pensando en ejecutar la aplicación en el EC2 de Amazon también). Sé que hay un proyecto que construye un servidor xmpp utilizando tornado, pero no está listo para su uso en producción y nuestra fecha límite no es tan grande. Básicamente, mi principal preocupación es la facilidad de desarrollo y de alguna manera lamentarme más tarde al utilizar pubsubhubbub para desarrollar una aplicación de chat, pero leí en algún lugar que PubSubHubbub eventualmente podría reemplazar a XMPP ya que REST reemplazó a SOAP, entonces, ¿qué piensas?

ACTUALIZACIÓN: ¿Conoce alguna solución de código abierto que utilice xmpp que admita MUC (público & privado) y PMs?

+0

Nota, PubSubHubbub (PuSH) ni siquiera está cerca de lo que es XMPP. PuSH es un protocolo de publicación-suscripción muy básico, con algo muy parecido a [Dialback] (http://xmpp.org/extensions/xep-0220.html) para la autenticación. XMPP es mucho más que no cabría en esta caja de comentarios. – Zash

Respuesta

11

Vaya para XMPP.

Fuera de la caja, ejabberd tiene soporte para todos sus requerimientos. No necesitará ver ningún erlang y escribir módulos personalizados para ejabberd. Y con Strophejs, XMPP en el navegador (que es lo que aparentemente está haciendo) es genial.

Para su última pregunta sobre el reemplazo de pubsubhubbub XMPP, no cuente con él. XMPP tiene más de 10 años de antigüedad, implementaciones sólidas de código abierto e interoperativas propietarias tanto en el cliente como en el servidor, y es elegante, por lo que no desaparecerá.

Y usted está desarrollando una aplicación de chat que es lo que XMPP está hecho para.

+0

Strophe se ve bien (también lo usa Aristochat). Gracias :) – Sofia

4

Facebook ¡Tornao no utiliza PubSubHubbub en absoluto!

Ve a XMPP, ha sido diseñado para lo que estás buscando. Tornado no fue diseñado específicamente para eso, sino para solicitudes de votación largas en general.

No es necesario usar Punjab, el módulo ejabbed http-bind hace un muy buen trabajo ahora. Además, no es necesario que aprendas Erlang, del mismo modo que no necesitas aprender C cuando escribes una aplicación web que usa Apache :) Mira cosas como Aristochat. Lo único con lo que tendrá que jugar es la configuración de su servidor XMPP y salas de chat, y luego, Javascript para el lado del cliente (en el navegador).

+0

Gracias. Aristochat parece prometedor. Mientras tanto, también se encuentra Speeqe (http://code.stanziq.com/speeqe). Los revisaré a los dos. De acuerdo con este http://www.readwriteweb.com/archives/where_is_the_real_time_web_message_bus.php tornado utiliza pubsubhubbub. – Sofia

0

PubSubHubbub (PuSH) nunca fue pensado para aplicaciones de chat en primer lugar. A veces se lo denomina "IM para la Web". Sugeriría que pases por esta diapositiva: Realtime Ruby for the Realtime Web by igrigorik

La pregunta realmente es ¿cuánto tiempo real quieres llegar? Si desea velocidad, XMPP es la mejor opción (500 ms) mientras que PuSH depende de su alimentación y cómo se retransmite. Recuerde, con PuSH es un total de 4 saltos de red antes de que el contenido llegue al suscriptor.

El problema aún mayor es que PuSH confía en HTTP Post. Incluso si terminas diseñando una aplicación de chat basada en PuSH, y dices en una etapa posterior, deseas que esté disponible para otros dispositivos o incluso como una aplicación de escritorio, deberías transmitir el mismo contenido usando XMPP. El otro lugar en el que se perderá es que sería muy difícil para los usuarios de su aplicación de chat iniciar sesión desde cualquier otra IM de su elección.

1

Si no necesita federación a través de XMPP pero desea prototipar e implementar rápidamente junto con la escalabilidad de fábrica, consulte el ejemplo de Lift web framework de chat server in one page of code.

0

Puede usar una API REST con WebSocket para implementar una arquitectura de editor/suscriptor.

Atmosphere y swagger sockets son un buen marco de java que puede agregar a su api de Jersey REST y lograrlo.

El blog del creador de Atmospehre, jfarcand, tiene una example of chat application construida con estas tecnologías.

Cuestiones relacionadas