7 de noviembre de 2005

Odio RSS

A veces me pregunto por qué hay tanto software odiable. La verdad es que la informática es una rama muy pesimista, te dedicas la mayor parte del tiempo a pensar en lo mucho que odias X, en lo mal hecho que está Y, o qué cantidad de drogas y alcohol tomó la madre del desarrollador Z durante el embarazo. En fin.

En realidad no odio a RSS en si, sino a la manera en que se ha construido todo. No, en realidad lo que odio es el protocolo HTTP 1.1. Oh, si, COMO LO ODIO, lo odiamos mucho ¿si?. Si, lo odiamos con todas nuestras fuerzas. ¿Por qué los agregadores de RSS tienen que BAJARSE TODO EL MALDITO RSS cada vez que quieren mirar si hay actualizaciones, maldita sea? ¿No sería más sencillo que el agregador pudiera mirar algo tan simple como "fecha en la que se actualizó por última vez expresada en tiempo unix"? ¿O algo como "hash de el archivo RSS que me sirva para indicar si debo bajarle o tengo suficiente con mi versión cacheada que es exactamente igual"? Cada vez que mi akregator mira a ver si hay actualizaciones de blogs se baja todos los RSS uno por uno, comiendome el ancho de banda de mi 56k.

No es cosa de broma. Se han escrito artículos en todo internet preguntando si RSS scala y si no podría colapsarse: Muchos sitios reciben cada hora visitas de miles de agregadores que ponen a su sitio en una situación similar a la de un ataque DOS. Echan la culpa al RSS, pero de que tiene la culpa RSS? RSS no "notifica" actualizaciones, solo describe datos y no puede hacerlo de mejor manera. Se habla de que algunos agregadores pasan de usar cabeceras HTTP del tipo "if-modified-since". Ah, las maravillas de HTTP.

En realidad, HTTP 1.1 tiene todo un bendito y largo capítulo al tema de cacheo. Tambien tiene soporte para decir el md5, porque podrias bajarte incorrectamente un html y pensar que tienes la ultima version. Claro, que nadie lo utiliza a efectos de cache, y el capítulo de cacheo habla sobre todo de fechas, que es absurdo para la mayor parte de los casos (es útil sin embargo para cosas como archivos gigantescos de los que hacer un md5 sería prohibitivo)

En mi opinión, lo ideal es que a HTTP se le pudieran dar instrucciones del tipo "dame el último tiempo de modificacion de tal página", o aun mejor "enviame el objeto foobar si su ultima fecha de modificacion no es tal", para ahorrar una ida y vuelta y ahorra latencia (ya de paso, no estaría mal que el puto pop3 tuviera una instruccion "retr and dele"). De hecho, creo que http tiene un campo de ese tipo, pero a saber que servidores lo implementan por defecot, que navegadores le hacen caso, y lo que es mas importante: ¿Por qué no han sacado una nueva versión que lo haga obligatorio? Permitiría que el navegador tuviera un cacheado perfecto: Estoy cansado de que firefox/ie/opera se "vuelva a bajar" cosas cada vez que visito páginas. Es más, estoy cansado de que cuando visito una página, y no ha cambiado NADA, tenga que bajarme la página DE NUEVO en vez de regenerarla completamente desde el cache que es lo que debería ocurrir.

Parte del problema es que http es un protocolo "sin estado": Pides una cosa, y el servidor ya no se acuerda de ti, no hay concepto de "sesion". Y que me perdonen si digo un sacrilegio, pero me parece una mierda que lo sea. ¿Por qué, que tiene de ventaja? HTTP tiene muy poco que ver con la naturaleza real de la web, la "web" lo único en lo que consiste es en leer archivos, nada más. Una especie de NFS, de sistema de archivos remoto. Si plan9 hubiera tenido éxito por cierto, http no seria necesario: Simplemente "montarias" el sistema de archivos del servidor en el espacio de nombres de tu proceso, y el navegador leeria archivos como si estuviera en local, dejando que el sistema los traiga y cachee en tu disco duro. ¿Necesitas mandar datos? Pues escribes a un archivo determinado, punto. La naturaleza "sin estado" de HTTP es la que obliga a los diseñadores web a añadir cadenas raras al final de las URLs para identificar a los usuarios entre diferentes cargas de páginas, para poder saber quien coño son.

El que HTTP sea un protocolo sin estado es tan absurdo que en la versión 1.1 se inventaron algo de conexiones persistentes para cambiarlo que supongo que estará basado en esto y luego se sacaron de la manga el keep-alive. Por supuesto: Eso no hace que HTTP deje de ser un protocolo "sin estado", sigue siendolo en el fondo a pesar de que le hayan incluido un parche. ¿Por que no se rediseño el estándar? Lo lógico e ideal, es que si yo voy a slashdot.org, me bajo la página, cierro el navegador y vuelva a la misma página, y que el navegador simplemente pida al servidor la información de fecha de ultima actualizacion de la pagina y de las imagenes en la página, y punto. El hecho de que tengamos una "recarga forzada" en los navegadores es el mejor signo visible de la debilidad del protocolo que utilizan. Y ahora mismo iba a empezar a pensar en javascript + css + html, el no-demasiado-óptimo sistema de recuperación de paquetes de TCP....oh dios...internet es un castillo construido con cimientos de arena sobre de una montaña de mierda.

2 comentarios:

  1. Anónimo3:34 p. m.

    Yo he hecho 2 proyectos sobre rss y ninguno funcionaba así. Uno leía el archivo hasta encontrar la fecha y si no era una actualización paraba, y el otro era una base de datos distribuida.

    Me parece muy raro que todos los agregadores bajen los feeds completos cada vez que comprueban la actualización. en fin. cosas más raras se han visto.

    miguel
    retratoensepia.com

    ResponderEliminar
  2. leer el archivo hasta encontrar la fecha no es que sea muy reconfortante de todas maneras :/

    ResponderEliminar