Siguiente Anterior Indice 

7. Fetchmail se hace mayor

Aquí estaba yo con un diseño nuevo e innovador, un código que sabía que funcionaba bien porque lo usaba todos los días, y una lista de desarrolladores desbordante. Me fui dando cuenta poco a poco de que ya no se trataba sólo de un proyectito personal que quizá les resultara útil a unas pocas personas más. Tenía en mis manos un programa que todo 'hacker' con un ordenador Unix y una conexión de correo del tipo SLIP/PPP necesitaba de verdad.

Con la posibiliad de realizar el reenvío a través de SMTP, se adelantó lo suficiente a la competencia como para poder llegar a ser el progrma dominante de este tipo, uno de esos clásicos que cumplen su cometido tan bien que las demás alternativas no sólo se descartan sino que casi caen en el olvido.

Creo que no es posible hacer planes para llegar a un resultado así. Te ves conducido a él por ideas para el diseño tan potentes que el resultado posterior parece simplemente inevitable, natural, incluso premeditado. La unica forma de encontrar este tipo de conceptos es disponer de un montón de ideas -- o teniendo el juicio y la habilidad ingenieril para llevar las ideas de los demás más lejos de lo que ellos creían posible.

Andrew Tanenbaum tuvo la idea original de construir un Unix nativo sencillo para el 386, con el fin de usarlo en enseñanza. Linus Torvalds llevó el concepto Minix probablemente mucho más lejos de lo que Andrew creía que podía llevarse -- y llegó a ser algo admirable. Del mismo modo (aunque a menor escala), cogí algunas ideas de Carl Harris y Harry Hochheiser y las desarrollé considerablemente. Ninguno de nosotros fue 'original' en el sentido romántico que mucha gente asocia a un genio. Sin embargo, la mayor parte de la ciencia, la ingeniería o el desarrollo del software no es realizada por genios, aunque la mitología 'hacker' mantenga lo contrario.

El resultado fue de todas formas bastante trascendental -- de hecho, fue el tipo de éxito que todo 'hacker' ansía lograr. Y eso hacía que tuviera que hacer mis estándares aún más exigentes. Para hacer 'fetchmail' tan bueno como ahora sabía que podía llegar a ser, tenía que escribir no solo para cubrir mis necesidades, sino también incluir y dar soporte a características necesarias para otros pero que quedaban fuera de mi ámbito. Y hacerlo al tiempo que mantenía la sencillez y robustez del programa.

La primera característica, y con diferencia la más importante, que añadí a continuación, fue el soporte para entregas múltiples -- la posibilidad de recoger el correo de puestos que habían acumulado todo el correo de un grupo de usuarios y enviar cada  uno de los mensajes a su destinatario particular.

Decidí añadirlo en parte porque algunos lo estaban pidiendo con insistencia, pero ante todo porque creí que contribuiría a sacar a la luz los errores que pudieran quedar en el modo normal de entrega simple al obligarme a poner en funcionamiento un sistema de entrega completamente general. Y así ocurrio. Conseguir implementar un intérprete de órdenes acorde a la norma RFC822 me llevó una considerable cantidad de tiempo, no porque hubiera algún trozo especialmente problemático, sino por un auténtico montón de detalles confusos e interdependientes.

Pero la decisión de soportar entregas múltiples resultó al final excelente. Me topé con lo siguiente:

14. Toda herramienta debe resultar útil en la forma prevista, pero una  *gran herramienta* te lleva a usarla para realizar cosas jamás pensadas.

Este uso imprevisto para la capacidad de realizar entregas múltiples consiste en gestionar listas de correo manteniéndolas y realizando la conversión de los alias en el lado cliente de una conexión SLIP/PPP. Esto permite que cualquiera que esté empleando una máquina personal conectada a Internet a través de una cuenta en un proveedor de las más corrientes pueda gestionar una lista de correo sin tener que acceder de manera continua a las listas de alias del proveedor de acceso a Internet.

Otro cambio importante que mis colaboradores pedían era el soporte para la codificación de mensajes MIME 8-bits. REsultó bastante fácil debido a que había tenido bastante cuidado en que el programa no interfiriera con su utilización. No es que me anticipara a esta petición, sino porque trataba de seguir otra regla importante:

15. Cuando escribas programas que actúen como pasarelas de datos ('gateway software'), ten cuidado de modificarlos lo menos posible -- y *nunca* elimines información a menos que su destinatario te fuerce a hacerlo.

Si no hubiera seguido esta regla, dar soporte a mensajes en código MIME 8-bits hubiera resultado difícil y propenso a errores. En cambio, lo único que hizo falta fue leer la norma RFC 1652 y añadir un poco más de lógica a la generación de cabeceras. Resultó bastante trivial.

Algunos usuarios europeos insistieron en que añadiera una opción para limitar el número de mensajes recogidos en cada sesión (de modo que pudieran controlar los costes ocasionados por sus carísimas líneas telefónicas). Me resistí durante mucho tiempo, y aún no estoy demasiado contento con el resultado. Pero si se escribe para todo el mundo, tienes la obligación de escuchar a tus clientes -- nada cambia a este respecto aunque no te estén pagando con dinero.


Siguiente Anterior Indice