2010-10-27 digital life Gedanken zu nmh Kritische Betrachtung MH (Mail Handler) ist ein Mail User Agent (MUA) (und etwas mehr als das) der Ende der 70er-Jahre entwickelt wurde. Nmh ist dessen Nachfolger. Nmh ist anders als alle anderen MUAs da er nicht monolithisch ist, sondern aus vielen Einzelprogrammen besteht die jeweils nur einen Teil erledigen. Es gibt beispielsweise `comp' um eine neue Nachricht zu verfassen (compose), `repl' um zu antworten (reply), `refile' um sie in einen anderen Ordner zu verschieben, `show' um sie anzuzeigen, und vieles mehr. Das ist der Ansatz der der Unix Philosophie folgt: Write programs that do one thing and do it well. Write programs to work together. [...] Aus diesem Grund mag ich nmh sehr und verwende es seit knapp einem Jahr. Momentan arbeite ich daran um ein paar nervige Unzulaengli- chkeiten auszubuegeln. Dabei bekommt man einen anderen Blick auf die Software. Die etwa 50.000 Zeilen C-Code erscheinen aeusserst kompliziert. Was an der Oberflaeche schoen in Einzelprogramme getrennt ist scheint im Code ziemlich verwoben zu sein. Von einer schoenen Aufteilung ist wenig zu sehen. Vielmehr sieht der Code eben aus wie der Code monolithischer Programme. Das enttaeuscht. Nun muss ich natuerlich klarstellen, dass dies ein erster Ein- druck ist und nicht das letzte Urteil. Vermutlich gibt es Separation die ich nur noch nicht sehe. Dennoch, alleine dass der Code monolithisch erscheint ist schon schlecht. Wenn Bolsky und Korn in ihrem Buch ``The KornShell: Command and Programming Language'' ein minimales MH implementieren -- nur zu Demozwecken der ksh -- dann erscheint das so elegant. Der tatsaechliche Code von nmh sieht eher heftig aus. Damit will ich keineswegs die Codequalitaet beurteilen, denn ich glaube dass die nmh workers faehige Programmierer sind. Mir geht es um die Gesamtstruktur der Codebasis. Sollte nicht etwas das an der Oberflaeche schoen aufgeteilt ist auch im Innern schoen aufgeteilt sein? Auch was die Konfiguration anbelangt bin ich nicht recht zufrieden. Einerseits ist sie auf einfache Weise wunderbar flex- ibel und ueberall lassen sich externe Programme einbinden doch es ist enorm viel Wissen noetig um das Gesamtsystem zu verstehen. Ist das ein grundsaetzlicher Nachteil den Toolchains mit sich bringen? Ich habe das Gefuehl, dass es besser moeglich sein muss. Das kann noch nicht das Ende sein. Ich bin gespannt ob ich spaeter, wenn ich nmh besser ken- nengelernt habe, diese Ansicht noch immer vertreten werde. Noch zu einer anderen Ueberlegung. Nmh ist genau genommen ein MUA sondern ein komplettes Mailsystem. Es hat einen eigenen Mail Transfer Agent (MTA) eingebaut und frueher beinhaltete es sogar einen POP-Server. An dieser Stelle geht nmh den falschen Weg; hier folgt es nicht der Unix Philosophie. Statt sendmail, fetch- mail und Co. -- die Spezialisten -- zu verwenden hat es alles selbst eingebaut. Das heisst, man kann natuerlich diese Pro- gramme auch verwenden aber eingebaut sind die Funktionen eben auch. nmh is the swiss-army knife of mail user agents. (Tatsaechlich ist nmh aber mehr als nur ein MUA, und das ist der Punkt.) Fuer mich sind Schweizer Taschenmesser -- die mit den 25 Funk- tionen -- Fehlschlaege. Im Sinne der Unix Philosophie hat man besser ein richtiges Messer, eine richtige Saege, einen richtigen Schraubenzieher -- die funktionieren besser und sind einfacher herzustellen, und zudem eher ohne Fehler. Ein dedizierter MTA macht seine Sache wahrscheinlich besser als der eingebaute MTA in nmh. Manche wuerden sagen, dass man den externen MTA ja verwenden koenne wenn man will -- weshalb steckt man dann aber Energie in das Mitschleppen und Weiterpflegen des eingebauten MTAs? Ich glaube nmh leidet insbesondere unter der Kompatibilitaet zu seiner Vergangenheit, aber auch unter ``Not Invented Here''. Beides ist letztlich schlecht und passt nicht recht zu Freier Software. Nmh will als ein Komplettpaket alles liefern was fuer Email noetig ist. Besser waere aber das Projekt wurde sich genauer und schmaeler definieren und abgrenzen; grosse Entwicklerkraft ist sowieso nicht mehr da. Ich glaube ein Fork wuerde nmh mal so richtig gut tun. Dann wurde der alte Ballast mal abgeschuettelt werden und es kaeme frischer Wind rein. Da nmh von anderer Software als Email- Backend verwendet wird muss Kompatibilitaet gewahrt bleiben. So ist eine Revolution nur ueber einen Fork praktisch moeglich. Trotz all der unschoenen Dinge die ich an nmh sehe gefaellt es mir noch deutlich besser als andere Mail-Clients. Vielleicht sollte ich ja mal in Heirloom mailx schauen bezueglich der Codes- truktur. Von aussen ist der jedoch klar monolithisch. Nmh ist im Ansatz klasse, doch die Umsetzung sollte noch besser moeglich sein. Ich sehe, es gibt viel zu tun. :-) Nachtrag: Nach weiterer Studie des Codes muss ich meine Sichtweise etwas korrigieren. Die kleinen und alten Tools (z.B. rmm, refile, packf, mark) sind durchaus einfach und klar zu lesen, ebenso viele der allgemein verwendeten Funktionen (z.B. context_read(), getarguments()). Die Verwobenheit und Undurchsichtigkeit ist in dem Code der modernes Emailing, sprich MIME, behandelt am staerksten. Aber schon Filterfiles bei repl z.B. machen die Sache kompliziert. Das eigentliche Problem liegt in der Natur modernen Emailings; darunter leidet eben auch nmh. http://marmaro.de/apov/ markus schnalke