En el mundillo python o incluso en el mundo web, es de sobra reconocido que como parser de feeds nada le hace sombra a feedparser. Por varias razones:

• Está escrito en python ;)
• Le podemos pasar casi cualquier tipo de URI como fuente de feed
• Parsea lo que le echemos: atom, rss, rss2. Incluso mal formados

Para hacer que funcione en mi móvil con un s60 he tenido que vérmelas hasta con la propia distribución de python de nokia: algún módulo que me falta, algún módulo que les ha dado por despiezar, ... Al final saber por qué no funcionaba ha costado. Así que antes que liarnos con explicaciones, he preparado un tar donde está todo lo necesario para hacerlo funcionar. Así que descargad feedparser para s60.

A la hora de instalar, hacer todo como python module salvo para testfp.py que es el programa de test. Al intentar instalar urlparse.py nos preguntará si queremos reemplazar la versión existente y le diremos que sí (tres métodos nuevos y unas cuantas constantes es lo que tiene de más).

Listo para servir.

Por si a alguien le sirve, que a mí me ha traído de cabeza últimamente... Al utilizar expresiones XPath con dom4j, si éstas tienen namespaces (espacios de nombres, xmlns="xmpp:xxx" ...), hay que usar siempre los prefijos o no funcionarán las búsquedas (al contrario que si usamos DOM pelado).

Para hacerlo tenemos que declarar antes los namespaces y luego usar los prefijos asignados:

Map namespaces = new TreeMap();
namespaces.put("x", "http://xmpp.org/namespaces/xxxx");
DocumentFactory.getInstance().setXPathNamespaceURIs(namespaces);

Y luego tendremos que prefijar todos los elementos de la búsqueda XPath que estén dentro de ese espacio de nombres:

String saan = elem.valueOf("//x:SubAdministrativeAreaName");

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.

Acabando de descubir xAL, un formato para la descripción de direcciones postales físicas, se lo comento a un compañero de curro:
- Vaya, hay un estándar para describir direcciones físicas...
- ¿Direcciones MAC?

Supongo que es lo que tiene estar en esto...

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>

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

Pues ahora ya puedo jugar ;)