Von meiner Software generierte Emails in TB speichern

  • Grüß Gott,


    nach über 12 Stunden vergeblicher Suche erhoffe ich hier eine Antwort auf mein Problem:


    Ich entwickle eine Software, die basierend auf einer komplexen Datenbank Emails mit sehr unterschiedlichen und individuellen Texten und Daten verschicken soll, wobei viele Emails auch manuell eingegebene Einfügungen enthalten.


    MalMerge scheidet also aus, abgesehen davon daß es überhaupt nicht in den nötigen Arbeitsfluß passen würde.


    Das "messages api" unterstützt einiges, aber NICHT das Speichern von Emails von außen.


    Ich habe keinen Weg gefunden, wie meine Software ihre Daten in Thunderbird zum Versand abstellen könnte, wobei alle Daten von meiner Software geliefert werden.


    Kennt hier jemand einen Weg?


    Eine Variante, die möglich sein könnte, wäre es ein JavaScript Add-on in Thunderbird einzufügen, das per http GET request an localhost alle nötigen Daten von meiner Software abholt. Meine Software verfügt bereits über einen internen Web-Server, so daß das kein Problem wäre. Jedoch bin ich nicht in die Tiefen der Add-on Entwicklung eingestiegen, zumal mir diese als extrem minimal erscheint.


    Als Notlösung habe ich bereits einen von Skripten getriebenen "Bot", der alle Daten aus meiner DB abholt und diese - vergleichbar einem Menschen - in Thunderbird über das normale UI einträgt. Das läuft faktisch aber nur in einer VM und es ist nicht ganz problemfrei.


    Vielen Dank für jeden Hinweis.


    P.S: MAPI scheint mir keine Lösung zu sein, einmal weil meine Software 100% MS-frei ist und ferner weil sie auch auf Linux laufen soll (Portierung der Kern-Software kein Problem).

  • graba

    Approved the thread.
  • wobei viele Emails auch manuell eingegebene Einfügungen enthalten.

    Wenn das bedeutet, dass der Benutzer die E-Mail im Thunderbird noch vor dem Senden bearbeiten können soll, dann schau dir die Kommandozeilenoptionen an. Siehe http://kb.mozillazine.org/Comm…guments_%28Thunderbird%29

    Damit kann direkt in ein vorbelegtes Verfassenfenster gestartet werden. Der Benutzer muss dabei immer noch selbst auf Senden drücken.

    Falls du genau das nicht möchtest, wüsste ich im Thunderbird keine Möglichkeit. In diesem Fall würde ich das Senden gleich aus deiner Software heraus erledigen. Entsprechende APIs gibt es in allen größeren Programmiersprachen. Damit wärst du unabhängig nicht nur vom Betriebssystem, sondern auch vom Mailprogramm.

    Falls kein IMAP vorausgesetzt werden kann, müsstest du den Absender in cc/bcc nehmen.

    Wer wenig oder gar nichts kann, schiebt's auf den Antiviruskram.

    (Compuzius, Buch 5)

  • Grüß Gott,


    danke für die Antwort.

    Quote


    dass der Benutzer die E-Mail im Thunderbird noch vor dem Senden

    Ja, aber natürlich nicht in Thunderbird, sondern NUR in meiner Software, denn nur da sind alle relevanten Informationen.


    Quote


    In diesem Fall würde ich das Senden gleich aus deiner Software heraus erledigen

    Es gibt diverse Gründe, genau das nicht zu tun. Die sind aber hier nicht relevant.


    Ich war wohl nicht präzise genug, darum noch mal in anderen Worten:


    Fix und fertig in meiner SW erzeugte und i.d.R. vom Benutzer vervollständigte Daten, also alles, was zu einer Email gehört, soll von dieser in TB gespeichert werden und dann meist etwas später durch Aktion des Benutzers (Knopf "Senden") versendet werden.


    Ich verstehe nicht, warum z.B. das "message API" zwar auslesen, löschen etc zuläßt, aber kein speichern. Nur das bräuchte es.


    Zusatzfrage 1:


    Ist es denn möglich, ein JavaScript Add-on in Thunderbird einzufügen, das per http GET request an localhost alle nötigen Daten von meiner Software abholt? Alternativ wären auch Sockets möglich, um Daten von meiner SW zu holen und in TB zu speichern.


    Zusatzfrage 2:


    Alternativ könnte meine SW die Daten auch selbst direkt in die SQLight DB von Thunderbird abstellen, aber auch dazu habe ich nichts gefunden.


    Mit scheint fast, man will bei Mozilla so etwas nicht!?


    Danke und Gruß

  • Hallo FrankB2,


    vielleicht ist hier eher der falsche Ort für Dein Anliegen.


    Interessant für Deine Anliegen wäre eventuell die Plattform Thunderbird | Topicbox und in dieser Plattform vielleicht die Diskussionsgruppe Add-on Developers | Topicbox. Verkehrssprache auf dieser Plattform ist Englisch.


    Gruß

    Feuerdrache

    „Innerhalb der Computergemeinschaft lebt man nach der Grundregel, die Gegenwart sei ein Programmfehler, der in der nächsten Ausgabe behoben sein wird.“
    Clifford Stoll, amerik. Astrophysiker u. Computer-Pionier

  • Fix und fertig in meiner SW erzeugte und i.d.R. vom Benutzer vervollständigte Daten, also alles, was zu einer Email gehört, soll von dieser in TB gespeichert werden und dann meist etwas später durch Aktion des Benutzers (Knopf "Senden") versendet werden.

    Mal um die Ecke gedacht: Thunderbird umstellen vom mbox-Format auf Einzelspeicherung (Edit: maildir-Format, danke @ Susi für die Erwähnung unmittelbar danach) und deine Software kann eine *.eml-Datei in den Entwürfe-Ordner ablegen ...? Bräuchte dann zwar mehr als einen Klick zum Abschicken, aber je nach Häufigkeit sicher noch beherrschbar.


    Alternativ könnte meine SW die Daten auch selbst direkt in die SQLight DB von Thunderbird abstellen, aber auch dazu habe ich nichts gefunden.

    M.W. liegen die Mails in keiner SQLite-DB. Wenn du abfängst, dass der TB nicht läuft und die Datei auch nicht anderweitig offen ist (z.B. durch eine weitere Instanz deines Programmes), müsstest du doch auch deinen Kram in die mbox-Dtei schreiben können; auch hier wieder die Entwürfe, um das im Programm dann absenden zu können?


    Mit scheint fast, man will bei Mozilla so etwas nicht!?

    Dein "so etwas" ist recht vage bzw. geht zwischen diversen verfügbaren Optionen hindurch, will mir scheinen.

    Susi to visit hat bereits Wege skizziert, von denen das durch deine Software zu erzeugende und zu füllende Verfassen-Fenster meinem Verständnis nach deine Anforderung recht gut erfüllt hätte.

    Und so sollte man wohl zurückfragen: fast scheint, du willst so etwas nicht?


    Vielleicht siehst du auch nur den Wald vor lauter Bäumen nicht und bist momentan zu fixiert auf einen ganz bestimmten Gedanken, so dass du durchaus nutzbare andere Optionen mit gleichem Ergebnis nicht mehr unvoreingenommen geprüft hat. Kenne ich, auch wenn meine bescheidene Programmiererzeit schon einige Jahrzehnte zurückliegt :)

  • Es gibt diverse Gründe, genau das nicht zu tun. Die sind aber hier nicht relevant.

    Ich halte es für einen schweren Fehler, wenn man sich bei der Entwicklung eines Programmes von einem anderen abhängig macht. Als Auftraggeber würde ich das auch ins Lastenheft schreiben. Denn sollte der Thunderbird irgendwann in der Zukunft nicht mehr der Mailer der Wahl sein, gibt es ein dickes Problem mit deiner Software.

    Ja, aber natürlich nicht in Thunderbird, sondern NUR in meiner Software, denn nur da sind alle relevanten Informationen.

    Das habe ich mir fast gedacht. Für den Thunderbird kann ich dir dann nicht weiterhelfen. Mir ist keine Lösung bekannt.


    Ist es denn möglich, ein JavaScript Add-on in Thunderbird einzufügen,

    Es gibt hier ein paar Add-On-Entwickler. Vielleicht können die dir weiterhelfen. Bedenke: Solche Add-Ons haben eine kurze Halbwertszeit. Das wirst du ständig pflegen und anpassen müssen.

    Fix und fertig in meiner SW erzeugte und i.d.R. vom Benutzer vervollständigte Daten, also alles, was zu einer Email gehört, soll von dieser in TB gespeichert werden und dann meist etwas später durch Aktion des Benutzers (Knopf "Senden") versendet werden.

    Ich verstehe nicht, warum z.B. das "message API" zwar auslesen, löschen etc zuläßt, aber kein speichern. Nur das bräuchte es.

    Ob die API das her gibt, ob man also von außen an die Funktionen des Thunderbird herankommt, kann ich dir nicht sagen. Wenn du das aber außerhalb einer API, also sozusagen "von Hand", machst, gibt es noch etwas zu bedenken. Es gibt seit einiger Zeit mit Maildir ein zweites Speicherformat. Das ist die Zukunft. Du müsstest dein Programm dann ggf. anpassen. Außerdem ist es mit dem Schreiben der E-Mails nicht getan, auch die mfs müssten aktualisiert werden, der Suchindex, usw. . Ohne API halte ich das für aussichtslos.

    Das alles ließe sich vermeiden, wenn du selbst senden würdest.


    Alternativ könnte meine SW die Daten auch selbst direkt in die SQLight DB von Thunderbird abstellen, aber auch dazu habe ich nichts gefunden.

    Thunderbird benutzt zum Speichern der E-Mails kein SQLight. Verwendet wird das alte Mbox-Format und eben das neue Maildir.

    Wer wenig oder gar nichts kann, schiebt's auf den Antiviruskram.

    (Compuzius, Buch 5)

  • Ein herzliches Grüß Gott


    und danke an alle, die mir so ausführlich geantwortet haben. Aus diesen Grund - und weniger, um hier noch eine Lösung zu finden, - antworte ich etwas ausführlicher als es vielleicht nötig wäre.


    Zuerst ein paar Fakten und Hintergründe:


    1) Ich entwickle nicht im Kundenauftrag, sondern arbeite an einer eigenen Familie von Standard-Software, der ein pur o-o Framework bisher im Unfang von über 80 Mannjahren zugrunde liegt (ca. 10K Applikations Klassen mit >200K Methoden), die über die letzten >20 Jahren entwickelt wurden. Heute nutze ich das älteste und mächtigste o-o System. An meine beiden früheren o-o Projekte in Obj-C und C++ erinnere ich mich nur mit Grausen. Ich bin o-o Pionier seit 1986.


    2) Das aktuelle Projekt ist ein kleiner und insgesamt eher unwichtiger Teil, der in 2- 3 Jahren sowieso durch ein viel umfassenderes Produkt ersetzt wird.


    3) Wichtiger Teil meines Gesamtkonzeptes ist auch mein eigenes Email-System (= viel mehr als nur ein Client), aber das kommt erheblich später, denn dafür müssen noch andere Dinge abgeschlossen werden, u.a. mein eigenes OODBMS (in Arbeit, Teile schon im Einsatz), denn die relationalen System sind für mich Steinzeit und Schrott, sowie ein ebenfalls pur o-o UI System, das auf GTK basiert aber vollständig datengetrieben. Steht noch aus.


    4) Mein Team und ich hatten anfangs der Nuller-Jahre für einen Großkunden eine vollautomatische Steuerung für MS Office, MS Outlook, den gräußlichen IE und für InDesign entwickelt. Das basierte alles auf dem für damals eigentlich recht guten COM-Interface. Das funzte prima, ist aber tot und eine MS-freie Alternative ist mir nicht bekannt. Auch will ich Linux unterstützen.


    Nun zu den einzelnen Vorschlägen (ich mache das mal kompakter ohne diese großflächige Zitat Funktion):


    eml-Dateien

    Klar, diese Idee kam mir schon ganz am Anfang, das ist aber m.E. nicht sinnvoll, denn ich kenne keinen Email-Client, der diese Dateien automatisch importieren und senden kann.


    mbox-Datei

    Mal irgendwo gehört, war mir aber bisher nicht im Detail bekannt. Danke für den Hinweis. Schaue ich mir an, bin aber skeptisch, denn allein schon, daß a) die TB-Software mich bei der Installation nicht fragt, wo ich denn meine Daten speichern möchte und b) die Umlagerung ein Drama ist (bei TB), stößt mich dabei komplett ab. Und auch ein anderes Format muß importiert werden können.


    man will bei Mozilla so etwas nicht!?

    Das bezog sich hierauf: "Ich verstehe nicht, warum z.B. das "message API" zwar auslesen, löschen etc zuläßt, aber kein speichern. Nur das bräuchte es." und auf das Abstellen von Daten in eine TB-DB, was aber meine Fehlannahme war.


    Um es mal direkt zu sagen: Wenn ein Unternehmen (mit der für mich extrem fragwürdigen Vergangenheit) wie Mozilla zwar alles ermöglicht, aber das mit Abstand wichtigste NICHT (speichern), dann muß das (meine Unterstellung: extrem böse) Absicht sein. Logische Gründe für so einen Quatsch kann ich mir trotz meiner extremen Phantasie nicht vorstellen.


    Zum Verständnis: Ich trauere heute noch den vielen teils sehr guten Add-Ons für FF nach, die vor ein paar Jahren verunmöglicht wurden. Und wenn ich diese perverse sadistische Art des Handlings von Bookmarks bei FF in winzigen Fensterchen sehe, geht jedesmal bei mir das Messer in der Tasche auf. Daß Chrome nicht besser ist, ist kein valides Argument.


    Wald vor lauter Bäumen

    Ist grundsätzlich richtig, aber mir sind keine Alternativen bekannt und komischerweise wird in den diversen Foren und Dokus, die ich gelesen habe, mein doch ganz simples, rudimentäres Anliegen kaum jemals erwähnt. Bin ich also so ein Exot?!


    "schweren Fehler, wenn man sich bei der Entwicklung eines Programmes von einem anderen abhängig macht"

    Richtig, meine ich auch. Aber nur weil ich jetzt mal drei Brötchen brauche, mache ich deswegen keine Bäckerei auf. Siehe oben. Ich habe mehrere Hundert Ideen für ein in vielen Features absolut neuartiges Kommunikations-System zusammen getragen (inkl. mit optional eigenem Server und P2P), das Teil meiner Familie sein wird, aber andere Dinge sind jetzt erst mal wichtiger. Fakt ist für mich, daß rund um Email seit über 20 Jahren absolute Stagnation herrscht. Nichts Neues unter der Sonne. Aber "meine Zeit" hierfür ist noch nicht.


    hier ein paar Add-On-Entwickler

    Danke, aber das mache ich dann lieber im Hause. Mit Externen habe ich fast nur schlechte Erfahrungen. Außerdem braucht das die Integration (also Kenntnis) in mein / mit meinem System. Außerdem generiere ich JS Code besser aus meinem Framework heraus, denn für die JS-Entwicklung mit flachen Dateien und den üblichen Editoren gilt für mich, was ich oben zu RDMBS schrieb.


    wenn du selbst senden würdest.

    Dazu müßte ich jetzt viel schreiben, um das zu erklären. Ich halte das derzeit für keine gute Lösung.


    Maildir

    Schon grob von gehört, nicht eingelesen. Aber das Format ist ja keine Lösung, wenn die TB-SW keinen automatischen Import ermöglicht.


    Das ist meine Entscheidung zur kurzfristigen Lösung

    Wenn auch hier keine Lösung zum eigentlich ganz trivialen Speichern von Emails "von außen" bekannt ist, wie bereits in den von mir dazu gelesenen anderen Quellen, dann dürfte es keine geben. Ich habe daher entschieden, das so zu machen wie in meinem OP erwähnt:


    "Als Notlösung habe ich bereits einen von Skripten getriebenen "Bot", der alle Daten aus meiner DB abholt und diese - vergleichbar einem Menschen - in Thunderbird über das normale UI einträgt. Das läuft faktisch aber nur in einer VM und es ist nicht ganz problemfrei."


    Übrigens werden auch diese Skripte bereits aus meinem Framework generiert, so daß ich alles an einer Stelle und in einem System habe.


    Vielen Dank für die Vorschläge und herzliche Grüße!



    P.S: Wenn "unsere Branche" mal nur zehn Prozent so innovativ wäre, wie Creti und Pleti sich das als DAUs so vorstellen....!

  • Zunächst einmal - ich hatte ich gar nicht richtig wahrgenommen, dass du stets so freundlich gegrüßt hast -


    Grüß Gott, FrankB2


    Ansonsten, puh, fällt mir nicht viel zu deinem letzten Posting ein. Spontan kommen mir Friedrich Hollaender und Marlene Dietrich in den in Sinn, aus meiner Uromas Zeit: "[...] Wünsche sind nur schön, solang sie unerfüllbar sind."


    Viel Erfolg.

    Wer wenig oder gar nichts kann, schiebt's auf den Antiviruskram.

    (Compuzius, Buch 5)

  • Grüß Gott


    (Gott in Dir, was es eigentlich meint), Mensch mit dem sehr ungewöhnlichen Nick!


    Zuerst kurz zu meinem Gruß: In diesen rein materialistischen Zeiten scheint es mir bitter nötig, ein winziges Zeichen gegen den Hauptstrom zu setzen, und wie gerade geschehen, fällt das manchmal sogar auf. Übrigens ist dieser Gruß im bayrischen Sprachraum, zu dem auch fast das gesamte "Ostreich" gehört (außer Vorarlberg und Teile von Tirol), auch heute noch durchaus gängig.


    Das folgende soll den einen oder anderen Kollegen hier ein wenig aus den üblichen Bahnen eigener eingetretener Hirnwege werfen und nur deswegen schreibe ich das:


    Dazu: "Wünsche sind nur schön, solang sie unerfüllbar sind." könnte ich sehr viel erzählen, mag es aber hier nicht, höchstens zwei Aussagen:


    1) Ich empfinde es als Gnade dieser meiner (sicher nicht ersten und sicher auch nicht letzten) Incarnation, daß ich mir sehr frühzeitig einen Beruf ausgesucht habe, in dem es einem - genug Einsatz, Intelligenz und "Glück" vorausgesetzt - durchaus möglich ist, "Großes" zu leisten, ohne sein Selbst verkaufen zu müssen. Ich war immer mein eigener Chef! In welcher anderen Branche wäre das sonst möglich, ohne dickes Kapital im Rücken und ohne die vielen dusseligen Manager, die alles besser wissen, aber i.d.R. hohle Nüsse sind. Die hab ich bei Kunden reichlich erlebt.


    2) Als logisch-kritisch denkfähiger "Analytiker" oft fremder Sachverhalte muß man irgendwann merken, daß es zwar Zufälle gibt, aber nicht so viele in einer Reihe und mehrfach logisch aufeinander aufbauend, wie es mir geschehen ist. Man kann das dem eigenen Genie zuschreiben, wofür es dann, wenn man das tut, aber wenig reale Gründe gibt. Oder man erkennt, daß dahinter eine (Lebens-)aufgabe steht, die einem "von außen" eingegeben wird.


    So ist es mir geschehen und zwar vielfach, wobei das bzw. mein Ziel nicht die Dinge sind, die man "im letzten Hemd" eh nicht mitnehmen kann. Wenn mal mal die 50 überschritten hat, sollte man auch an so etwas denken.


    Aber wenn man zum dritten Mal von einem Traum mit genialen Ideen aufgewacht ist, um diese notieren zu können, wenn man zum xy-ten Male (bei mir sicher schon lange dreistellig) gleich nach dem Aufwachen nicht selten geniale Konzepte im Kopf hat sowohl zu Technik, Marketing und Produkten, dann MUSS man erkennen, daß etwas und auch im sehr weiten Sinne "jemand anderes" dahinter steckt als das eigene Ego. Dabei sind die vielen kleinen Fälle nicht eingerechnet, etwa unter der Dusche, beim Kaffeekochen oder gar dort, wohin der Kaiser allein geht!


    Darum bin ich mir sicher, daß der größte Teil dessen, was andere mir als Wünsche oder Phantasien unterstellen, durch die beiden genannten Aspekte realisiert werden kann - und ich habe hier nur einen Bruchteil erwähnt. Ob das aber so kommt, diese Entscheidung liegt nicht bei mir, ich tue nur das mir Mögliche, aber OB es so kommt, das entscheidet jemand anderes, vielleicht die metaphysische Quelle der Eingaben (ich weiß es nicht).


    Zuletzt das Wichtigste und mein Motto seit >15 Jahren: "Nur die Wahrheit wird uns befreien". Die Quelle ist schnell gefunden (im Original leicht anders formuliert) und darüber nachzudenken lohnt sich - ganz besonders in diesen (w)irren Zeiten! Versprochen!


    Herzliche Grüße!