Boa tarde meus queridos!
No versículo de ontem vimos a 14ª parte da tradução de “The Cathedral and the Bazaar”. A 15ª vemos hoje.
O Fetchmail Cresce
Lá estava eu com um design elegante e inovador, código que eu sabia que funcionava bem porque eu o usava todos os dias e uma lista beta crescente. Aos poucos, percebi que eu não estava mais envolvido em um hack pessoal trivial que poderia ser útil para algumas outras pessoas. Eu estava com minhas mãos em um programa que todo hacker com uma caixa Unix e uma conexão de email SLIP / PPP realmente precisa.
Com o recurso de encaminhamento de SMTP, ele se distanciou da concorrência para potencialmente se tornar um “matador de categorias”, um daqueles programas clássicos que preenchem seu nicho com tanta competência que as alternativas não são apenas descartadas, mas quase esquecidas.
Eu acho que você não pode realmente mirar ou planejar um resultado como esse. Você tem que ser atraído por idéias de design tão poderosas que depois os resultados parecem inevitáveis, naturais, mesmo pré-ordenados. A única maneira de tentar idéias como essa é ter muitas idéias – ou ter o julgamento de engenharia para levar as boas idéias de outras pessoas para além de onde os criadores achavam que poderiam ir.
Andy Tanenbaum teve a idéia original de construir um Unix nativo simples para PCs da IBM, para uso como ferramenta de ensino (ele chamou de Minix). Linus Torvalds levou o conceito Minix mais longe do que Andrew provavelmente pensou que poderia ir- e se transformou em algo maravilhoso. Da mesma forma (embora em menor escala), peguei algumas idéias de Carl Harris e Harry Hochheiser e as forcei. Nenhum de nós era “original” da maneira romântica que as pessoas pensam ser genial. Mas então, a maioria das ciências e engenharia e desenvolvimento de software não é feita pelo gênio original, a mitologia hacker contrariamente.
Os resultados foram muito atraentes – de fato, exatamente o tipo de sucesso pelo qual todo hacker vive! E eles significava dizer que eu teria que definir meus padrões ainda mais altos. Para fazer o fetchmail tão bom quanto eu vi agora que poderia ser, eu teria que escrever não apenas para minhas próprias necessidades, mas também incluir e suportar recursos necessários para outros, mas fora da minha órbita. E fazer isso enquanto mantinha o programa simples e robusto.
O primeiro e mais importante recurso que escrevi depois de perceber isso foi o suporte a multidrop – a capacidade de buscar e-mails de caixas de correio que haviam acumulado todos os e-mails para um grupo de usuários e rotear cada parte de email aos seus destinatários individuais.
Eu decidi adicionar o suporte multidrop em parte porque alguns usuários estavam clamando por ele, mas principalmente porque eu pensei que isso iria tirar os bugs do código single-drop, forçando-me a lidar com o endereçamento em geral. E assim foi provado. Receber a análise de endereços RFC 822 levou-me muito tempo, não porque qualquer parte dela seja difícil, mas porque envolvia uma pilha de detalhes interdependentes e exigentes.
Mas o endereçamento multidrop acabou se revelando também uma excelente decisão de projeto. Veja como eu sabia:
- Qualquer ferramenta deve ser útil da maneira esperada, mas uma ferramenta realmente excelente se presta a usos que você nunca esperou.
O uso inesperado para o multidrop fetchmail é executar listas de distribuição com a lista mantida e a expansão de pseudônimos concluída no lado do cliente da conexão com a Internet. Isso significa que alguém que esteja executando uma máquina pessoal por meio de uma conta de provedor de serviços de Internet pode gerenciar uma lista de distribuição sem continuar acessando os arquivos de pseudônimos do ISP.
Outra mudança importante exigida pelos meus beta-testers foi o suporte para a operação MIME (Multipurpose Internet Mail Extensions) de 8 bits. Isso foi muito fácil de fazer, porque eu tinha tido o cuidado de manter o código limpo de 8 bits (ou seja, não pressionar o 8º bit, não utilizado no conjunto de caracteres ASCII, em serviço para transportar informações dentro do programa). Não porque eu antecipasse a demanda por esse recurso, mas sim em obediência a outra regra:
- Ao escrever software de gateway de qualquer tipo, esforce-se para perturbar o fluxo de dados o mínimo possível – e nunca jogue fora as informações, a menos que o destinatário o obrigue!
Se eu não tivesse obedecido a essa regra, o suporte a MIME de 8 bits teria sido difícil e cheio de bugs. Como estava, tudo o que eu tinha que fazer era ler o padrão MIME (RFC 1652) e adicionar um pouco de lógica trivial de geração de cabeçalho.
Alguns usuários europeus me incentivaram a adicionar uma opção para limitar o número de mensagens recuperadas por sessão (para que possam controlar os custos de suas caras redes telefônicas). Eu resisti a isso por um longo tempo, e ainda não estou totalmente feliz com isso. Mas se você está escrevendo para o mundo, precisa ouvir seus clientes – isso não muda só porque eles não estão pagando em dinheiro.
Fim da décima quinta parte. Nos vemos amanhã com a próxima. Deus os abençoe!
