Boa tarde povo!
No último versículo vimos a parte 12 de “The Cathedral and the Bazaar”, hoje vemos a parte 13.
Popclient se Torna o Fetchmail
O verdadeiro ponto de virada no projeto foi quando Harry Hochheiser me enviou seu rascunho de código para encaminhar emails para a porta SMTP da máquina cliente. Percebi quase imediatamente que uma implementação confiável desse recurso tornaria todos os outros modos de entrega de mensagens obsoletos.
Por muitas semanas eu estive aprimorando o fetchmail de forma incremental, enquanto sentia que o design da interface era útil, mas sujo – deselegante e com muitas opções exíguas por toda parte. As opções para despejar mensagens buscadas em um arquivo de caixa de correio ou na saída padrão me incomodavam particularmente, mas eu não conseguia descobrir por quê.
(Se você não se importa com a “tecnicália” de email da Internet, os próximos dois parágrafos podem ser ignorados com segurança.)
O que vi quando pensei em encaminhamento de SMTP foi que o popclient estava tentando fazer muitas coisas. Ele foi projetado para ser um agente de transporte de email (MTA) e um agente de entrega local (MDA). Com o encaminhamento de SMTP, ele poderia sair do negócio do MDA e ser um MTA puro, entregando correio para outros programas para entrega local, assim como o sendmail faz.
Por que mexer com toda a complexidade de configurar um agente de entrega de mensagens ou configurar travar-e-anexar em uma caixa de correio quando a porta 25 é praticamente garantida em qualquer plataforma com suporte a TCP/IP? Especialmente quando isso significa que as mensagens recuperadas são garantidas como mensagens SMTP iniciadas pelo remetente, o que é realmente o que queremos de qualquer maneira.
(Voltando para um nível mais alto …)
Mesmo que você não tenha seguido o jargão técnico anterior, há várias lições importantes aqui. Primeiro, esse conceito de encaminhamento de SMTP foi o maior retorno que obtive ao tentar conscientemente copiar os métodos de Linus. Um usuário me deu essa ótima idéia – tudo o que precisei fazer foi entender as implicações.
- A próxima melhor coisa a ter boas ideias é reconhecer boas ideias dos seus usuários. Às vezes, o último é melhor.
Curiosamente, você descobrirá rapidamente que, se você é completamente e auto-depreciativamente verdadeiro sobre o quanto você deve a outras pessoas, o mundo em geral irá tratá-lo como se você fizesse sozinho todas as partes da invenção e estivesse apenas se tornando modesto sobre seu gênio inato. Todos nós podemos ver o quão bem isso funcionou para Linus!
(Quando dei minha palestra na primeira Conferência Perl, em agosto de 1997, o extraordinário hacker Larry Wall estava na primeira fila. Quando cheguei à última linha acima, ele gritou: “Diga, conte, irmão!” Toda a platéia riu, porque eles sabiam que isso havia funcionado para o inventor de Perl também.)
Depois de algumas semanas de execução do projeto com o mesmo espírito, comecei a receber elogios semelhantes não apenas de meus usuários, mas de outras pessoas para as quais a palavra vazava. Eu guardei um pouco desses emails; Eu vou olhar de novo algum dia se eu começar a pensar se minha vida valeu a pena :-).
Mas há mais duas lições fundamentais, não políticas, que são gerais para todos os tipos de design.
- Muitas vezes, as soluções mais impressionantes e inovadoras vêm de perceber que seu conceito do problema estava errado.
Eu estava tentando resolver o problema errado continuando a desenvolver o popclient como um MTA / MDA combinado com todos os tipos de modos de entrega local. O design do Fetchmail precisava ser repensado desde o início como um MTA puro, uma parte do caminho normal de correio da Internet que fala SMTP.
Quando você atinge uma parede em desenvolvimento – quando se vê difícil de pensar além do próximo patch -, é sempre hora de perguntar não se você tem a resposta certa, mas se está fazendo a pergunta certa. Talvez o problema precise ser reformulado.
Fim da décima terceira parte, amanhã domingo a décima quarta. Abraços!
