7. Fetchmail Grows Up
|
7. Fetchmail dospívá
|
|
There I was with a neat and innovative design, code that I knew worked
well because I used it every day, and a burgeoning beta list. It
gradually dawned on me that I was no longer engaged in a trivial
personal hack that might happen to be useful to few other people. I
had my hands on a program every hacker with a Unix box and a SLIP/PPP
mail connection really needs.
|
V ruce jsem měl uspořádanou a originální konstrukci, kód, o kterém jsem věděl, že funguje, neboť jsem ho používal každý den a rostoucí seznam testovatelů. Postupně mi docházelo, že už se nezabývám programováním něčeho jednoduchého, co může být užitečné pro několik dalších lidí. Měl jsem v rukou program, který potřebuje každý hacker s Unixem a SLIP/PPP poštovním připojením.
|
|
With the SMTP forwarding feature, it pulled far enough in front of the
competition to potentially become a ``category killer'', one of those
classic programs that fills its niche so competently that the
alternatives are not just discarded but almost forgotten.
|
Se SMTP přesměrováním se fetchmail dostal daleko do čela konkurence a stal se potenciálním vládcem kategorie, takovým, který vyplní svůj prostor tak dokonale, že alternativy nejsou pouze odmítnuty, ale i téměř zapomenuty.
|
|
I think you can't really aim or plan for a result like this. You have
to get pulled into it by design ideas so powerful that afterward the
results just seem inevitable, natural, even foreordained. The only
way to try for ideas like that is by having lots of ideas -- or by
having the engineering judgment to take other peoples' good ideas
beyond where the originators thought they could go.
|
Myslím si, že takový výsledek skutečně nemůžete plánovat. Musí Vás k němu dovést vývojový plán tak silný, že při zpětném pohledu se zdají výsledky nevyhnutelné, téměř předpověditelné. Jedinou možností, jak dostat takový nápad, je mít mnoho nápadů, nebo mít inženýrský úsudek a dovést nápady někoho jiného až za hranici toho, co si autor původní myšlenky dokázal představit.
|
|
Andrew Tanenbaum had the original idea to build a simple native Unix
for the 386, for use as a teaching tool. Linus Torvalds pushed the
Minix concept further than Andrew probably thought it could go -- and
it grew into something wonderful. In the same way (though on a
smaller scale), I took some ideas by Carl Harris and Harry Hochheiser
and pushed them hard. Neither of us was `original' in the romantic
way people think is genius. But then, most science and engineering
and software development isn't done by original genius, hacker
mythology to the contrary.
|
Andrew Tanenbaum přišel s původní myšlenkou vystavět jednoduchý Unix pro 386 jako učební pomůcku. Linus Torvalds dotáhl koncept Minixu dále, než si zřejmě Andrew mohl představit a vzniklo z něj něco úžasného. Stejným způsobem (ačkoliv v menším měřítku), jsem převzal nápady Carl Harrise a Harry Hochheisera a dotáhl jsem je do konce. Vždyť většina vědy, inženýrství a softwarového vývoje není vytvářena nějakým originálním geniem, ač to hackerské bájesloví tvrdí.
|
|
The results were pretty heady stuff all the same -- in fact, just the
kind of success every hacker lives for! And they meant I would have
to set my standards even higher. To make fetchmail as good as I now
saw it could be, I'd have to write not just for my own needs, but also
include and support features necessary to others but outside my orbit.
And do that while keeping the program simple and robust.
|
Výsledky byly přesto fantastické, ve skutečnosti to byl právě takový úspěch, po kterém každý hacker touží. A to znamenalo, že si musím sám pro sebe nastavit ještě náročnější kritéria. Abych učinil fetchmail tak dobrý, jak jen jsem si byl schopen představit, musel jsem psát nejen pro své vlastní potřeby, ale rovněž zahrnout podporu, kterou jsem nepotřeboval sám, ale jiní uživatelé. A při tom všem jsem musel udržet program jednoduchý a stabilní.
|
|
The first and overwhelmingly most important feature I wrote after
realizing this was multidrop support -- the ability to fetch mail from
mailboxes that had accumulated all mail for a group of users, and then
route each piece of mail to its individual recipients.
|
První a zdaleka nejdůležitější funkcí, kterou jsem přidal po té, co jsem si vše uvědomil, byla podpora vícenásobného stahování, možnost stáhnout poštu z poštovních schránek, které obsahovali poštu více uživatelů a poté ji distribuovat jednotlivým příjemcům.
|
|
I decided to add the multidrop support partly because some users were
clamoring for it, but mostly because I thought it would shake bugs out
of the single-drop code by forcing me to deal with addressing in full
generality. And so it proved. Getting RFC 822
parsing right took me a remarkably long time, not because any
individual piece of it is hard but because it involved a pile of
interdependent and fussy details.
|
Rozhodl jsem se tuto funkci přidat, protože někteří uživatelé po ní toužili, ale zejména proto, že mě to přinutí řádně prohlédnou současnou verzi a objevit chyby, které ve snaze napsat mnohem obecnější postup vyplavou na povrch.
|
|
But multidrop addressing turned out to be an excellent design decision
as well. Here's how I knew:
|
Ukázalo se, že se také jednalo a výborné konstrukční rozhodnutí.
|
|
14. Any tool should be useful in the expected way, but a
truly great tool lends itself to uses you never
expected.
| 14. Jakýkoliv nástroj by měl být užitečný očekávaným způsobem, ale opravdu velké nástroje se hodí na použití, které jste nikdy neočekával |
|
The unexpected use for multi-drop fetchmail is to run mailing lists with the
list kept, and alias expansion done, on the client side of
the SLIP/PPP connection. This means someone running a personal
machine through an ISP account can manage a mailing list without
continuing access to the ISP's alias files.
|
Tak tento přepsaný fetchmail byl neočekávaně využit při správě diskuzních skupin.
|
|
Another important change demanded by my beta testers was support for
8-bit MIME operation. This was pretty easy to do, because I had been
careful to keep the code 8-bit clean. Not because I anticipated the
demand for this feature, but rather in obedience to another rule:
|
Další důležitou změnou, kterou ode mne požadovali moji testovatelé, byla podpora 8-bit MIME. To bylo docela snadné, neboť jsem si dával pozor, abych nijak nepozměnil 8 bit. Nebylo to proto, že bych předvídal tento požadavek, spíše jsem se řídil dalším pravidlem:
|
|
15. When writing gateway software of any kind, take pains to disturb
the data stream as little as possible -- and *never*
throw away information unless the recipient forces you to!
|
15. Pokud píšete zprostředkovatelský software jakéhokoliv druhu, snažte se vlastní data nijak neměnit a nikdy se nezbavujte žádné informace, pokud vás k tomu nedonutí příjemce.
|
|
Had I not obeyed this rule, 8-bit MIME support would have been
difficult and buggy. As it was, all I had to do is read RFC 1652
and add a trivial bit of header-generation logic.
|
Kdybych se tímto neřídil, podpora 8-bitového MIME by byla obtížná a s chybami. Takto mi stačilo prečíst si standard a přidat něco triviální logiky při generaci hlaviček.
|
|
Some European users bugged me into adding an option to limit the
number of messages retrieved per session (so they can control costs
from their expensive phone networks). I resisted this for a long
time, and I'm still not entirely happy about it. But if you're
writing for the world, you have to listen to your customers --
this doesn't change just because they're not paying you in money.
|
Někteří evropští uživatelé mne přemlouvali, abych přidal omezení počtu vzkazů stáhnutelných při jednom sezení (aby mohli kontrolovat cenu svých drahých telefonních linek). Dlouho jsem tomu vzdoroval a stále s tím nejsem zcela spokojen. Pokud ale píšete pro celý svět, musíte naslouchat svým zákazníkům, to se nemění jenom proto, že nejste placen penězi.
|