Y como hay quien no espera la llegada de las rebajas, Google acaba de comprar Jaiku, lo cuentan en su blog. Jaiku se podía entender como una especie de Twitter, pero menos centrado en el mandar mensajitos y más en la agregación de la identidad digital. Yo he llegado a usar Jaiku, sin hacerle mucho caso, aunque a veces entro simplemente para ver cómo es capaz de agregar toda mi vida digital de forma tan sencilla: las fotos de flickr, este blog, mis sitios de 11870, mi del.icio.us, ...

Si alguno de vosotros ha utilizado facebook, habrá descubierto el vicio que es echar un vistazo al news feed de nuestra home donde vemos todo lo que hace nuestra gente dentro de facebook. Lo bonito de Jaiku es que es abierto y se nutre de los feeds que nosotros le demos y de las relaciones que traslademos al sistema.

Pero lo que realmente me llamó la atención de Jaiku fue su aplicación para el móvil. En mi N70 la integración era terrorífica: los contactos, el estado (si el móvil lo pones en modo reunión se actualiza el estado en Jaiku), la posición geográfica (vía gps o triangulando estaciones), mandar mensajes, invitar a contactos de la agenda, ... En serio, de repente el móvil tenía alguna de las cosas que asocias claramente al futuro. Si todavía no la habéis probado, echadle un vistazo. Por cierto, el cliente utiliza XMPP para la comunicación con el servidor... buen estándar nunca muere.

Y enhorabuena al equipo de Jaiku oye, que es una gran noticia ;)

A Google le está dando por implementar determinada funcionalidad en Google Talk un poco a su manera. Un claro ejemplo son las últimas funcionalidades que han implementado: transferencia de ficheros y carpetas y buzón de voz. Prometen, por supuesto, documentar el funcionamiento con un JEP, pero tardarán. También prometen liberar una nueva versión de libjingle que será capaz de trabajar con las nuevas funcionalidades.

Pero los curiosos como yo lo único que podíamos hacer era montar un sniffer y observar el XML que se transfería en los momentos clave. Pero resulta que son un poco más listos que eso en Google y hay opciones de línea de comando para obtener el mismo resultado sin tanto jaleo:

    /log verbose tstamp thread file

Eso nos dejará un bonito fichero en el escritorio con el volcado del XML transferido. Para verlo en una consola en vez de en un archivo, sustituir file por debug.

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 ;)