UTOI, ese monstruito

UTOI es un proyecto que viene de largo. Concretamente, el primer módulo [para Apache] que se desarrolló, UTOI::inutoi, es de 20080709, hace más de un año. ¿Por qué tanto tiempo? Durante este último año no hemos parado de hacer cosas nuevas y la envergadura de UTOI siempre le iba dejando en una segunda posición de prioridades.

Desde principios de este año, tras lanzar El Selector, UTOI ha ido ganando poco a poco toda nuestra atención y todo MET, junto con Diseño, se han ido incorporando progresivamente al proyecto.

La envergadura de UTOI es equiparable, muy probablemente, al de esos primeros seis meses de soitu.es donde desarrollamos todas las herramientas (editores, motor de publicidad, despliegue de hardware, etc.) y se diseñaron todas las plantillas que soportan este portal.

Pero, ¿qué es UTOI?

UTOI puede significar tres cosas, elige la que más te guste:

• Es, claramente, un juego con la palabra SOITU. Si te fijas a UTOI sólo le falta la 's'. El guiño es directo :).
• Leelo en inglés, U-to-I. O sea, you-to-I directamente comunicados :).
• Un asturiano te podría decir "¿U ta pa?" y tú, perfectamente, contestarle un simple "Pa ta pa Ponga". "¿U toi?" es "¿dónde estoy?" en asturiano :).

Como ves, nada de simbolismos. Siempre claros y concisos :).

¡¿Hmmmmmmm?!

Vale, vale... :)

Seguramente, si este último año no has utilizado la técnica del avestruz [con tu cabeza], habrás oído hablar del fenómeno Twitter. En soitu.es lo vimos claro hace mucho tiempo y, por eso, UTOI empezó en cuanto tuvimos un ratito el verano pasado. La inmediatez del mensaje/utoi es lo importante: quiero decir algo y puedo, inmediatamente, desde donde sea, lo clasifico en el tema correspondiente y, además, lo transmito con toda la riqueza al alcance. Luego ya podré ampliarlo, escribir un artículo, ensayo o lo que sea, pero el utoi está lanzado. Informativamente, es un cañón.

Para centrarnos técnicamente... UTOI es, esencialmente, un API público que permite acceder a todo el potencial de nuestro sistema de mensajería. La primera prueba de ese potencial es acceder a utoi.es porque ese entorno web está montado sobre el API, aquel al que todos vosotros tenéis acceso desde ya mismo.

Hay herramientas maravillosas ahí afuera pero, siempre, les echamos de menos cosas y, por eso, surge la necesidad de UTOI. No hablaré de razones estratégicas, que Borja Echevarría os desgranará en breve, y que creo, sinceramente, que son las más importantes; sólo hablaré de las funcionales:

• Hilos: hay que poder seguir de una forma fácil toda una conversación ya iniciada, si no te pierdes y no entiendes nada.
• El concepto tema, evento, grupo o interés común debe ser posible. Es decir, a mí me puede gustar mucho escribir de tecnología —que va a ser que no porque lo mejor es practicarla :)— pero, además, lo que esté escribiendo puede tener que ver con fotografía, ¿por qué si me gustan esos dos temas, no puedo enviar mi utoi a ambos? Y, es más, si no me atrevo a escribir sobre ello, ¿por qué, al menos, no puedo leer todo lo tratado sobre ambos? Desde nuestro punto de vista, organizar temáticamente la información es fundamental y hemos trabajado mucho en ello con soitu.es. Desarrollaremos clasificaciones automáticas, que se superpongan sobre otras, pero la primera, los temas, es fundamental para UTOI.
• Relaciones. No es un secreto nuestra relación especial con Autonomy, ¿cómo no vamos a poder relacionar todos los utois que hablan de lo mismo automáticamente? ¿Extraer contenido de las URLs enlazadas y saber, mejor aún, de qué estás hablando? Grandes partes de todo esto están aún por poner a punto o, incluso, por desarrollar pero serán, posiblemente, las que mayor impacto tengan a futuro porque harán que mensajes, o información, diseminada pase a estar organizada, relacionada y se enriquezca entre sí.
• Casi siempre, una imagen --o un vídeo-- vale más que unos pocos cientos de caracteres. Si UTOI se convierte en una herramienta informativa de primer orden, no podría no soportar imágenes.
• Simplicidad. Por ejemplo, todos tenemos —desafortunadamente— un móvil y enviar un pensamiento a UTOI debería ser tan fácil como enviar un SMS, ¿no? ¿Conectarse a Internet? ¿Arrancar no sé qué? Pero, si estoy tirado en no sé dónde y casi no tengo ni cobertura. ¡Na! Un SMS y puerta... Pues eso, al 5195.
• Por último, ¿qué me decís de la estabilidad? Informativamente es absolutamente impensable que una plataforma falle cuando más la necesitas. Obviamente puede pasar --y nadie está a salvo de ello-- pero la estabilidad y la escalabilidad de la plataforma deben estar presentes en el diseño del proyecto desde el principio.

Técnicamente, ¿mucho lío?

Un follón de tres pares... En una escala del 1 al 10, sería... como un 17, más o menos :). El soporte nativo para hilos y el concepto de evento con multienvío complicaron el diseño de una forma exponencial. Por supuesto, siempre con esos mandamientos de estabilidad y escalibilidad revoloteando.

La dimensión del mismo hizo que, durante el camino de desarrollo, surgieran otros proyectos que pasaron antes a producción que el propio UTOI: uno de ellos es CORT.AS, nuestro acortador de URLs, y, el otro, una librería de "pensamientos" que nos permite abstraer las interconexiones de soitu.es con servicio externos como, por ejemplo, Twitter o FriendFeed.

En titulares (un siguiente artículo describirá UTOI con una profundidad técnica mucho mayor):

• UTOI está desarrollado en Perl y en C, con interfaces de salida JSON y XML. Otros formatos de salida están previstos y, en parte, funcionando.
• Esto hace que UTOI, realmente, sea un API y el cliente web accesible desde utoi.es sea "sólo" eso, un cliente :).
• Se han incrustado módulos en el Apache, en Perl, y en el NGINX, en C.
• UTOI está diseñado como un sistema de múltiples colas asíncronas y desacopladas pero procesables con la mayor rapidez posible. O sea, la pretensión es simular un modelo síncrono pero sin serlo realmente.
• Los procesadores de mensajes vuelven a estar hechos en Perl y en C, dependiendo de si la complejidad o el rendimiento eran las prioridades.
• No usamos base de datos SQL, usamos TokyoCabinet y TokyoTyrant. No es un secreto nuestra pasión por el modelo clave/valor desde hace años. Aquí, sería impensable alcanzar el rendimiento pretendido con una bb.dd. tradicional. Además, el hecho de que esté desarrollado en C, con sus librerías correspondientes, se ajusta perfectamente a nuestras necesidades.
• Aunque valoramos el uso de TokyoTyrant para el almacenamiento de datos temporales, decidimos seguir con MemCached porque el rendimiento es superior.
• El sistema soporta múltiples clientes/inyectores, con múltiples almacenes de datos (ya sea en modo maestro-maestro o maestro-cliente) y con miles de conexiones siendo servidas a la vez.

Futuro

Todo por delante... Realmente no hemos hecho más que arrancar. Lo primero, probablemente, será estabilizarlo todo y comprobar que el diseño que hemos creído bueno lo es realmente.

No dudes en escribirnos en el Tablón UTOI todas las dudas, problemas o sugerencias que te surjan.