Había estando modificando 'fetchmail' durante varias semanas de forma progresiva pero no dejaba de notar que el diseño de la interfase era utilizable pero poco presentable -- muy poco elegante y con demasiadas opciones de uso poco frecuente dando vueltas por ahí. Las opciones para volcar el correo recogido a un fichero 'mailbox' o a la salida estándar me preocupaban de manera especial, pero no terminaba de entender la razón.
Lo que ví cuando pensé sobre el reenvío a un servidor SMTP era que 'popclient' había intentado hacer demasiadas cosas. Había sido diseñado para ser a la vez un agente de transporte de correo ("mail transport agent" MTA) y un agente de envío de correo local ("local delivery agent" MDA). Con el reenvío a un servidor SMTP, podía salir del mundo MDA y convertirse en un MTA auténtico, encargándose de remitir el correo a otros programas para su entrega local del mismo modo en que lo hace 'sendmail'.
¿Qué necesidad hay de lidiar con la complejidad de configurar un agente de envío de correo o con el bloqueo y la adición a un fichero 'mailbox' si existe una garantía casi total de que la puerta 25 se encuentre disponible desde el principio en cualquier plataforma que soporte TCP/IP?. En especial cuando eso significa que el correo que se recoja tiene la garantía de aparecer como un correo normal SMTP remitido desde el lugar de origen, que es lo que en verdad andamos buscando.
Hay varias lecciones que extraer de aquí. En primer lugar, que esta idea de realizar un reenvío al servidor SMTP fue la mayor contribución individual que obtuve al intentar imitar los métodos de Linus. Un usuario me dió una idea tan brillante -- y todo lo que tuve que hacer por mi parte fue comprender sus implicaciones.
11. La siguiente cosa mejor que tener buenas ideas consiste en reconocer las buenas ideas de tus usuarios. Y en ocasiones ésta última es la mejor en términos absolutos.
Resulta bastante interesante observar que uno se da cuenta enseguida de que si se es completa y generosamente verídico acerca de cuanto le debes a los demás, el resto de la humanidad te tratará como si fueras el responsable de hasta la última porción de un invento y considerará que estás siendo simplemente modesto respecto a tu indiscutible genialidad. ¡No hay más que ver lo bien que este efecto funcionó con Linus!
(Cuando presenté esta comunicación en la conferencia Perl en Agosto de 1997, Larry Wall estaba sentado en la primera fila. Al llegar a la última línea citada anteriormente, exclamó: "Dí que sí, dí que sí, tío". Todos los presentes rieron, porque sabían que también le había ocurrido exactamente igual al inventor de Perl).
Y después de unas pocas semanas de conducir el proyecto de esta forma, comencé a recibir un reconocimiento similar no solo de mis usuarios, sino también de otra gente a la que le habían llegado noticias indirectamente. Guardé a buen recaudo algunos de aquellos mensajes de e-mail; y los leeré de nuevo si alguna vez me pregunto si mi vida ha servido para algo útil.
Pero hay aquí dos lecciones fundamentales más, nada políticas, que pueden aplicarse a cualquier clase de diseño.
12. A menudo, las soluciones más sorprendentes e innovadoras surgen al darte cuenta de que la idea que se tenía del problema estaba equivocada.
Había tratado de resolver el problema equivocado al continuar desarrollando 'popclient' como una combinación MTA/MDA capaz de realizar cualquier suerte de entrega local del correo por extraña que pudiera resultar. El diseño de 'fetchmail' debía ser rehacerse por completo, planteándolo como un MTA puro, como una parte más del camino habitual del correo en Internet regulado mediante dialogos SMTP.
Cuando topas con una pared en un desarrollo dado -- cuando te ves obligado a pensar más allá de cual va aser el próximo parche -- suele ser el momento de plantearte no si tienes la respuesta adecuada, sino si estás respondiendo la respuesta correcta. Quizá el problema necesita ser replanteado.
Bueno, había replanteado mi problema. Estaba claro que lo más adecuado era (1) transformar el soporte para redireccionar el correo mediante SMTP en el driver genérico, (2) fijarlo como el modo de funcionamiento por defecto, y (3) eliminar cuando fuera posible las demás formas de entrega de correo, en especial las opciones de entrega a fichero y a la salida estándar.
Estuve dudando algún tiempo sobre la conveniencia de poner en práctica la tercera etapa, temiendo perjudicar a aquellos antiguos usuarios de 'pop-client' que dependían de los modos alternativos de entrega de correo. En teoría, podrían pasar inmediatamente a emplear ficheros '.forward' o sus equivalencias alternativas al empleo de 'sendmail' para conseguir los mismos resultados. Pero en la práctica, la transición hubiera podido crearles un cierto lío.
Pero cuando terminé por hacerlo, los beneficios fueron enormes. La parte más problemática del driver desapareció. La configuración se hizo muchísimo más simple -- ya no había necesidad de andar buscando el MDA del sistema o el fichero 'mailbox' del usuario, ni era preciso preocuparse de si el sistema operativo sobre el que se ejecutaba soportaba o no el bloqueo de ficheros.
Además, despareció la única posibilidad de que se perdiera el correo. Si intentabas entregar el correo en un fichero y el espacio en disco se acababa, lo perdías. Algo que no puede pasar mediante la redirección en SMTP por cuanto el receptor SMTP no devolverá un OK a menos que el mensaje se haya entregado o al menos se haya puesto en lista de espera para entregarlo en cuanto sea posible.
Por otra parte, la velocidad aumentó (aunque no tanto como para poderlo notar en un uso ocasional). Otro beneficio nada insignificante del cambio consistió en que la página 'man' del programa se hizo mucho más sencilla.
Más adelante, hube de reintroducir la posibilidad de realizar la entrega a través de un MDA local para poder trabajar en algunas oscuras situaciones relacionadas con el uso de SLIP dinámico. Pero encontré una manera mucho más sencilla de hacerlo.
La moraleja?. No dudes en eliminar posibilidades ya caducas cuando sea posible hacerlo sin pérdida de efectividad. Antoine de Saint-Exupery (que fue aviador y diseñador de aeroplanos antes que autor de libros clásicos para niños) decía que:
13. ``La perfección (de un diseño) no se consigue cuando no queda nada por añadir, sino más bien cuando no resta nada por eliminar.''
Cuando tu código se hace mejor y más sencillo, es cuando notas que es correcto. El diseño de 'fetchmail' adquirió su propia identidad en este proceso, una distinta a la de su antepasado 'popclient'
Había llegado el momento de cambiarle el nombre. El nuevo diseño se parecía más a un asistente de 'sendmail' de lo que lo había sido el entiguo 'popclient'; ambos son del tipo MTA, pero mientras 'sendmail' remite los mensajes y luego los envía, el nuevo 'popclient' los recoge y luego los envía. Tras dos meses de esfuerzos, le cambié el nombre a 'fetchmail'.