Después de un fin de semana un tanto ajetreado para el servidor jabber de JabberEs (cambio de disco, cambio de IP, actualización de ejabberd), ahora parece que le ha tocado el turno al servidor que tiene la web, alojado en la UJI.

Paciencia.

Actualización: Ya tenemos el servidor web de vuelta.

Hoy, hace apenas unos minutos, JabberEs ha tenido 200 usuarios conectados de forma simultánea. Es un número considerable pero se queda un poco corto si pensamos que JabberEs tiene ya un año y medio. Aunque menos vale quejarse con los aprietos que pasó el proyecto hace unos seis meses (nos quedamos literalmente sin servidor Jabber).

¿Que qué es Jabber? Mensajería instantánea. Libre. Abierta. Interoperable. No controlada por corporaciones. Sin publicidad. Te puedes montar tu servidor. O el de tu asociación. O el de una universidad.

Si no lo has probado, hazlo ya. Por cierto, mi JabberID es peralta@jabberes.org.

El particular servicio de JabberEs, eduardo, que indica el estado en el que te encuentras con tu cliente de mensajería instantánea libre en tu página web, ha superado los 300 usuarios. Todo un hito ;)

PD: ¿Qué todavía no sabes qué es Jabber? Créate una cuenta ya.

Desde hace algún tiempo llevo teniendo ganas de meterle más caña al Pub/Sub de Jabber, y más teniendo el componente instalado en nuestro servidor.

De nuevo, para el desinformado: pubsub es una tecnología estilo PUSH, donde cualquier ente (JID en nuestro caso) puede suscribirse a una fuente de datos. Si algún ente envía datos (publica) en dicha fuente, se manda a todos los suscritos. Analogía: las listas de correo o los grupos de noticias. Ventajas: XML, utilizable para consumo entre aplicaciones o entre aplicaciones y usuario.

Pongamos un ejemplo: mi colega XuZo participa en el desarrollo de un reproductor basado en GStreamer, eina. Pongamos que quiere saber qué canciones reproducen más los usuarios, por simple curiosidad. Entonces, podría utilizar pubsub para enviar ese dato a una fuente pubsub, teniendo como único suscriptor a sí mismo (sería el caso de varios publicadores y un único suscriptor o comunicación aplicación y usuario). Otra posibilidad, jugando con la misma idea sería que el único suscriptor fuese una pequeña aplicación encargada de hacer estadísticas para luego publicarlas en otra fuente, a la que estaría suscrito XuZo. Como vemos, se ha complicado un poco la cosa. El tercer ejemplo sea quizá el más interesante: que las mismas instancias de eina publiquen en un nodo o fuente (al que está suscrito el generador de estadísticas) y estén suscritas a otro (en el que se publican las estadísticas). De esta forma, eina podría mostrar en todo momento la canción más reproducida por todos los usuarios de la aplicación en un momento dado.

En realidad, el envío de la canción en curso por parte de eina al servicio de estadísticas no tiene porqué ser a través de pubsub, porque no necesitamos el reenvío masivo.

Con esto espero haber explicado más o menos de qué va el asunto del pubsub y porqué puede ser interesante este tipo de comunicaciones entre aplicaciones.

El quid de la cuestión era otro. En el servidor de JabberEs tenemos un componente pubsub, pero me resultaba imposible crear nodos (fuentes) en él. Yo mandaba ésto:

<iq to='pubsub.jabberes.org'
    type='set'
    id='xx'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <create node='test/ja'/>
  </pubsub>
</iq>

Que, en un principio, es correcto, tal y como dice el JEP. La respuesta, sin embargo, no daba a entender que lo fuera:

<iq from='pubsub.jabberes.org' 
    to='peralta@jabberes.org/siemens/cert'
    type='error' xml:lang='en' id='xx'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <create node='test/ja'/>
  </pubsub>
  <error code='405' type='cancel'>
    <not-allowed
 	xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

Resulta que el componente pubsub de ejabberd (y, por consecuencia, de JabberEs) quiere que los nodos se creen en su sitio, lo que significa, según el autor de ejabberd que mis nodos los debo crear en home/jabberes.org/peralta/ (analogía un poco a los directorios de usuario UNIX).

Pues ahora ya puedo jugar ;)

Hace unos dias estuve entretenido desarrollando un bot de recetas o consejos para JabberEs. El objetivo del bot es modificar el mensaje del día (motd) del servidor, de forma que a los usuarios que se conectar por primera vez un determinado día reciben un mensaje.

El contenido de este mensaje es abierto, lo que significa que cualquiera puede contribuir mandándonos su consejo. Lo que intentamos con ésto es que se conozcan más los servicios que ofrecemos.

Para sorpresa mía, a algún usuario de nuestro servidor, estos mensajes le están resultando molestos (y creo que también a algún admin :P), con lo que he decidido que las actualizaciones se realicen con al menos dos dias de lapso...