Resumen

La pregunta era pequeña; el trabajo no

«¿Cuánto vale esta cantidad en otra moneda?» parece una consulta de una sola línea. Para un bot en un canal de IRC, implicaba encontrar los datos, pedirlos a un servidor y repetir el proceso de forma fiable. En el relato del propio proyecto, Stenberg explica que localizó HttpGet, una utilidad de línea de comandos publicada por el brasileño Rafael Sagula el 11 de noviembre de 1996. Añadió cambios y el 17 de diciembre apareció una versión que los incorporaba. Dar a Stenberg la autoría original de HttpGet borraría el primer eslabón; presentar curl como si hubiera nacido en 1996 borraría el nombre y la evolución posteriores.

HttpGet empezó con una promesa estrecha: obtener datos por HTTP. En 1997, recibió direcciones HTTP en la línea de comandos y soporte de proxy. El proyecto también reparó Gopher y añadió descargas FTP. Los datos que necesitaba el bot, y otros datos útiles, ya no cabían bajo una etiqueta de un solo protocolo. En agosto, la versión 2.0 adoptó urlget. El registro de versiones deja ver continuidad técnica bajo el cambio de rótulo.

La tinta del nuevo nombre apenas se había secado cuando llegó otro problema. Las cargas FTP y HTTP POST introdujeron el envío de datos. Una herramienta llamada «obtener URL» estaba ejecutando operaciones que iban en la dirección contraria. El usuario todavía veía un comando, pero el trabajo real se había convertido en transferir. Cada ampliación respondía a una necesidad ejecutable; ninguna exigía fingir que el programa anterior nunca había existido.

El nombre siguió al código

El 20 de marzo de 1998 salió curl 4. Que el número fuera cuatro importa: no era una creación desde cero. La nueva palabra liberaba al proyecto de prometer únicamente recuperación, HTTP o FTP. SSL, cookies y otras funciones se sumaron durante 1998, según la cronología; no hay que amontonarlas todas en la fecha del cambio de nombre. El mecanismo se volvía más capaz a medida que chocaba con las condiciones de los servidores reales.

Había una barrera que el nombre por sí solo no resolvía. Si otro programa quería usar el motor de transferencia, lanzar un proceso externo y leer su salida era una unión torpe. En la primavera de 2000, el proyecto reorganizó el código para ofrecer una interfaz de biblioteca. La versión 7.1, del 7 de agosto, incorporó la interfaz «easy». Su registro de cambios no habla en eslóganes: enumera símbolos de libcurl, cabeceras instalables, construcción de biblioteca compartida y llamadas para fijar opciones. Son las piezas que permiten a otro desarrollador escribir contra una interfaz.

La historia oficial registra un enlace de terceros a libcurl aparecido ese mismo agosto. Es una pista concreta de adopción: alguien fuera del núcleo del proyecto pudo tratar la herramienta como componente. El manual actual de la API de C muestra la secuencia de configurar, ejecutar y limpiar una transferencia. No todos sus detalles actuales pertenecen a 2000; la novedad de entonces fue hacer invocable el motor desde el programa ajeno.

El ahorro estaba detrás de la interfaz

HttpGet describía una operación y un protocolo. urlget amplió los protocolos. curl dejó de fijar la dirección del movimiento. libcurl trasladó la transferencia detrás de una API que otros podían elegir. Los nombres cuentan la historia de los límites que el código había sobrepasado, no una sucesión de campañas de marca.

El bot necesitaba un dato; los programas siguientes necesitarían muchos. Mantener una implementación común de protocolos, proxies y estados de transferencia ofrecía una salida más barata que reinventar el mismo intercambio en cada aplicación. También concentraba poder de mantenimiento en una interfaz pública. Una pregunta de divisas terminó poniendo precio al trabajo repetido que nadie quería hacer de nuevo.