nicht angemeldet
Hallo Alexander, ich finde es ganz bestürzend, was du da schreibst. Ein unvoreingenommener Leser würde beim Lesen deiner zwei Beiträge den Eindruck erhalten, dass Email::* ganz schlecht und M::L zu bevorzugen ist, obwohl das Gegenteil der Fall ist; zumal deine Kritik aus einer nur sehr oberflächlichen Betrachtung entspringt, weil du nach eigener Aussage noch gar nicht mit Email::* programmiert hast!
Der Textmenge nach zu beurteilen, findest du, das größte Problem ist die Qualität der Dokumentation. Tatsächlich ist M::L der Vorteil nach reiner Menge zu gewähren. Du unterschlägst aber, dass es zu Email::* Synopsen und Beispielcode gibt, mit denen die Libs genutzt werden können, und das nicht nur /mit Ach und Krach/, /geradeso für den Regelfall/, wie man mutmaßen könnte, sondern vollständig. Ich würde der Doku keine 6, sondern eine 3 geben. Dies ist leicht nachzuvollziehen, wenn man sich erst mal länger als fünf Minuten mit ihr beschäftigt, um etwas zu programmieren und nicht nur zum Sichten durchklickt. Aber genug zu dem Thema, auf lange Sicht gesehen ist die Doku kein wesentlicher Faktor verglichen mit anderen Kriterien – Doku konvergiert zur guten Qualität; das ist ohnehin ein Merkmal, wo Email::Sender sehr mühelos aufschließen kann.
Email::MIME kann auch E-Mails zusammenbauen. Nur ist dann Schluß.
Das ist beabsichtigt so! M::L begeht einen schlimmen Designfehler, Mail-Erstellung und -Versand in eine Klasse zu packen. Besser gelöst ist das mit der Hierarchie Email::*, die unter dem Schirm vom PEP (ehemaliges Wiki durch archive.org erreichbar) miteinder kompatible Klassen bietet, die genau jeweils eine Sache korrekt lösen.
Letztes Release: 3.027 vom 10. Oktober 2009. Ich sehe da keine neun Jahre
[...] Aber: MIME::Lite wird weiter entwickelt
Ein Releasedatum macht meine Aussage nicht ungültig. Siehe stattdessen das Changelog! M::L läuft auf Sparflamme, der Maintainer rjbs richtet verständlicherweise seine Energie lieber auf die modernen Email::*-Module. Es gibt schlicht keine Weiterentwicklung oder Zukunft für M::L: er will auch persönlich, dass M::L für neue Projekte nicht mehr benutzt wird.
Drei Dutzend sind 36 [nicht 33]
Diese Antwort empfinde ich als Korinthenkackerei. Ich drücke meine Absicht wohl besser deutlich aus:
um mal Bugs zu zählen
Man kann ganz klar schlussfolgern, dass obwohl die Email::*-Module auch schon eine lange Lebensdauer auf dem Buckel haben, sie wegen der aktiven Pflege wesentlich besser im Vergleich zu M::L wegkommen. Die Benutzung von M::L ist ein Risiko, solange es niemanden gibt, der es wieder aufmöbeln will.
nicht kompatibel mit Email::Abstract,
Na und? Ziel von MIME::Lite ist es nicht, EMails zu parsen, sondern sie zusammen zu bauen [...]
Sorry, da hast du das Ziel von E::A falsch aufgefasst. Häufig hat man ja schon ein Emailobjekt im Speicher! Es ist nur möglich, es von M::L verarbeiten zu lassen, wenn man es ressourcenraubend serialisiert. Dies wäre einfach vermeidbar, wenn M::L kompatibel wäre.
wirft keine Exceptions im Fehlerfall
Kann ich mir nicht so recht vorstellen
Ist aber so. Ich kann nicht genug betonen, wie schlimm eigentlich dieser Nachteil ist! Wenn man M::L einsetzt, geht Mail schlichtweg verloren. Harsch, aber wahr. Mailsysteme sind wohl eine der unzuverlässigsten Infrastrukturen im Internet, und das Modul trägt dem überhaupt keine Rechnung. Im Bestfalle kriegt man Bouncemails (hat der Programmierer, der M::L einsetzt, sich darauf korrekt und RFC-konform vorbereitet? eher nicht.) oder Meldungen im Log vom MTA (nur vom Postmaster/Root einsehbar), im ungünstigsten Falle ist die verschickte Mail einfach weg. Auf jeden Fall ist es immer zu spät. Email::Sender hat die einzig korrekte Implementation (mittels Schema von Erfolg, Teilerfolg, Fehler) vorzuweisen, so dass der Programmierer gezwungen ist, sich mit Fehlerfällen vom MTA unmittelbar auseinanderzusetzen; man kann die Exception abfangen und zeitnah behandeln. Selbst ein Programmcrash durch Exception ist besser als zu tun, als ob alles in Ordnung wäre – bedenke den typischen Einsatz vom OP in diesem Thread.
Dieses Merkmal allein sollte als Gnadenschuss gegen M::L ausreichen.
sicherer als wenn man irgendwelche Daten selbstgestrickt in sendmail pumpt
Der Vergleich war zwischen M::L und Email::Sender, nicht M::L und sendmail. Prinzipiell ist alles besser als sendmail-Pumpe.
Konnte ich es schaffen, dich zum Umdenken zu bewegen? Ich habe nur gute Absichten zur Förderung des besten Moduls für den jeweiligen Zweck im Sinn.
Struppi