In den letzten Monaten gab es in verschiedenen Discourse-Gruppen mehrere Anfragen nach Verbesserungen der Verarbeitung eingehender E-Mails. Als User Stories ausgedrückt, lassen sich diese Anfragen grob wie folgt kategorisieren:
- „Ich möchte die Möglichkeit haben, dieselben HTML-Funktionen zu nutzen, wenn ich per E-Mail antworte, wie auch beim Posten auf der Website.“
- „Ich möchte die Möglichkeit haben, Nachrichten aus unserer Mailingliste anzusehen und zu durchsuchen.“
- „Ich möchte, dass per E-Mail erstellte Inhalte, sowohl über die Antwort-funktion als auch über den Massimport, konsistent gut formatiert und korrekt verarbeitet werden.“
Ich werde unten auf reale Beispiele dieser Anfragen verlinken, aber zunächst ist es wichtig zu verstehen, dass jede dieser drei „unterschiedlichen“ Anfragen im Kern dasselbe fordert – eine präzisere Verarbeitung eingehender E-Mails.
Vor einigen Monaten habe ich @sam geschrieben, um die Möglichkeit zu prüfen, dass Discourse die kommerzielle E-Mail-Verarbeitungs-API nutzen kann, die unser Unternehmen anbietet. Sam schlug vor, hier einen explorativen Beitrag zu verfassen, um die Vorteile zu erläutern, die eine Integration unserer API gegenüber der bestehenden Lösung für die Verarbeitung eingehender E-Mails in Discourse bietet, und zudem zu erklären, wie unsere API als Plugin integriert werden könnte.
Ich werde beide Themen im Detail behandeln, beginnend mit dem aktuellen Stand der E-Mail-Verarbeitungslösung in Discourse. Und zum Nutzen aller, die sich in den letzten Jahren nicht intensiv mit der E-Mail-Verarbeitung beschäftigt haben, werde ich zudem einige Hintergrundinformationen zum Problem liefern.
Dieser Beitrag ist recht lang, aber Sie können gerne springen. Hier ist eine Übersicht dessen, was behandelt wird:
- Der aktuelle Stand der E-Mail-Verarbeitung in Discourse
- Die Vorteile einer besseren E-Mail-Verarbeitung
- Stakeholder-User-Personas
- Die FWD:Everyone E-Mail-Verarbeitungs-API
A. Entfernen von Signaturen und Antworten
B. Normalisierung von HTML-Markup
C. Sprachunterstützung
D. Styling mit CSS - Vorgeschlagene Integration
- Testen der API
Der aktuelle Stand der E-Mail-Verarbeitung in Discourse
Discourse verfügt bereits über eine Funktion „Antwort per E-Mail“, die E-Mail-Antworten von Nutzern in neue Forenbeiträge innerhalb eines Themas umwandelt. Diese Funktion funktioniert wie folgt:
- Ein Nutzer erhält eine E-Mail-Benachrichtigung mit einem neuen Beitrag in einem Forumsthema, das er verfolgt.
- Der Nutzer antwortet auf diese E-Mail.
- Diese E-Mail-Antwort wird in einen neuen Beitrag im entsprechenden Forumsthema umgewandelt.
Konzeptionell ist dies eine unschätzbare Funktion; sie ist der bevorzugte Arbeitsablauf für viele Menschen und ein Muss für viele mailinglistenbasierte Gemeinschaften, die eine Migration zu Discourse in Erwägung ziehen.
Das Problem ist jedoch, dass diese E-Mail-Antworten, wenn sie in Forenbeiträge umgewandelt werden, oft mit fehlender oder falscher Formatierung oder sogar mit fehlendem Text gerendert werden. Dies ist aus Gründen, die ich unten erläutern werde, höchst problematisch.
Häufige Probleme sind:
- Aufzählungspunkte werden nicht korrekt dargestellt
- Fehlende Zeilenumbrüche zwischen Texten
- Zusätzliche Zeilenumbrüche zwischen Texten
- Vom Nutzer geschriebener Text wird vollständig gelöscht
Und wenn ich sage, dass diese Probleme häufig auftreten, meine ich nicht, dass sie gelegentlich beim Senden von E-Mails in Fremdsprachen mit obskuren E-Mail-Clients vorkommen. Vielmehr meine ich, dass sie häufig beim Senden grundlegender Antwort-funktion-Nachrichten von Gmail und Outlook auf Englisch auftreten.
Hier sind zwei reale Beispiele für Nutzer, die sich über diese Probleme beschweren, beide von der [Python-Dev]-Mailingliste:
https://www.prettyfwd.com/t/Wco-c1ZCR7mUwiww0j6s9w/#message-5
https://www.prettyfwd.com/t/Wco-c1ZCR7mUwiww0j6s9w/#message-36
(Prettyfwd nutzt die FWD:Everyone E-Mail-Verarbeitungs-API.)
Obwohl ich noch keine Inhalte aus bestehenden Mailinglisten mit Discourse importiert habe, kann ich aus Erfahrung sagen, dass die Fehlerrate beim Rendern ganzer E-Mail-Threads mindestens eine Größenordnung höher ist als die Fehlerrate bei der Antwort-funktion. Dies liegt an der erhöhten Komplexität beim Entfernen von Signaturen und Antworten, der Berücksichtigung von Inline-Antworten, dem Umgang mit tief verschachteltem Markup usw.
Als reales Beispiel verweist dieser Rückblick auf die Migration von Mailman zu Discourse, geschrieben von Tanya Lattner (Präsidentin der LLVM-Stiftung), in dem Abschnitt zu technischen Bedenken auf diese Probleme:
Ich habe nachgefragt, und es stellt sich heraus, dass das spezifische Problem, das sie beklagen, der hohe Anteil an E-Mails ist, denen Inhalte fehlen, weil sie vorzeitig abgeschnitten wurden. Da die vorherigen Diskussionen und Dokumentationen aus den letzten 19 Jahren des Mailinglisten-Archivs von unschätzbarem Wert sind, fühlen sie sich, bis dieses Problem vollständig gelöst ist, nicht in der Lage, Mailman abzuschalten.
Also, wie wissen wir, ob der aktuelle Stand der E-Mail-Verarbeitung in Discourse „gut genug“ ist? Ich schlage folgenden dreiteiligen Härtetest vor:
- Nutzer müssen voll darauf vertrauen können, dass ihre Inhalte, wenn sie die Antwort-funktion nutzen, korrekt verarbeitet werden und genauso gut aussehen, als hätten sie sie über die Web-Oberfläche gepostet.
- Forenadministratoren müssen darauf vertrauen können, dass die Erlaubnis der Antwort-funktion keine zusätzlichen Arbeiten und Beschwerden verursacht.
- Die Mitarbeiter von Discourse müssen der Funktion so sehr vertrauen, dass sie sie aktiv als erstklassige Beteiligungsmöglichkeit bewerben.
Sofern wir nicht mit vollem Vertrauen sagen können, dass jede dieser Bedingungen erfüllt ist, werden selbst bei Vorhandensein der Antwort-funktion bei weitem nicht die meisten potenziellen Vorteile realisiert.
Das ist derzeit der Fall.
Das heißt, ich würde den bestehenden Code zur E-Mail-Verarbeitung als 80-20-Lösung bezeichnen, aber in einem Kontext, in dem eine 80-20-Lösung nicht wirklich Sinn ergibt; das Problem ist, dass selbst wenn beispielsweise 80 % der E-Mails korrekt verarbeitet werden, Sie wahrscheinlich nicht einmal 10 % der potenziellen Vorteile erhalten.
Obwohl die Antwort-funktion (und der Massimport von E-Mails) bereits existieren, erhalten Nutzer letztendlich nicht das Erlebnis, das sie suchen, es entstehen zusätzliche Arbeiten für Moderatoren und Mitarbeiter, Gemeinschaften verlieren wertvolle Inhalte und Nutzerwachstum usw.
Die Vorteile einer besseren E-Mail-Verarbeitung
Soziale Software ist nur so erfolgreich, wie sie menschliche Bedürfnisse erfüllt.
Die Gründe, warum Leute in Webforen posten, umfassen den Wunsch, Wissen mit anderen zu teilen, ihre Meinungen zu beeinflussen, als allgemein intelligent wahrgenommen zu werden, als Fachexperten, als wertvolle reale Beiträge zu leisten usw.
Und wenn es um textbasierte Kommunikation geht, hängt die Wahrscheinlichkeit, diese Ergebnisse zu erzielen, nicht nur davon ab, was gesagt wird, sondern auch von der Typografie, mit der es gesagt wird.
Das ist der Grund, warum es ganze Bücher über Leerzeichen bei Shakespeare gibt. Es ist teilweise der Grund, warum die NY Times ernster genommen wird als die NY Post. Und es ist ein großer Teil des Grundes, warum Facebook MySpace besiegt hat.[1]
Wenn der Text, den ein Nutzer schreibt, durch kein Verschulden seinerseits schlecht formatiert wird, werden die menschlichen Bedürfnisse, die Menschen dazu bewegen, soziale Software zu nutzen, nicht mehr erfüllt. Tatsächlich passiert das Gegenteil; die Nutzer werden dumm dastehen lassen.
Selbst Nutzer, die die Antwort-funktion nicht verwenden, verlieren Autorität und Respekt, wenn andere Beiträge im Thema (und im größeren Forum) wie ein Müllfeuer aussehen.
Stakeholder-User-Personas
Während alle profitieren, wenn Beiträge konsistent mit ästhetisch ansprechender Typografie gerendert werden, gehören zu den User-Personas, die besonders von einer besseren Verarbeitung eingehender E-Mails profitieren könnten:
- Personen, die derzeit Mitglieder von Mailinglisten wie [Python-Dev] und [Django-Dev] sind, die die Vorteile von Discourse voll verstehen und sich freuen, ihre Gemeinschaften zu Discourse zu verlagern, aber nur, wenn sie in einer Weise weiter teilnehmen können, die von GNU Mailman, Google Groups usw. nicht zu unterscheiden ist. Hier ist ein reales Beispiel für eine solche Anfrage: https://www.prettyfwd.com/t/Wco-c1ZCR7mUwiww0j6s9w/#message-89
- Mitglieder von E-Mail-basierten Gemeinschaften, die im Allgemeinen gerne zu Discourse migrieren würden, aber viel enthusiastischer wären, wenn ihre jahrzehntelangen bestehenden Inhalte innerhalb derselben Plattform leicht durchsuchbar wären.
- Gelegentliche Nutzer, die Foren nur sporadisch prüfen. Zum Beispiel bin ich auf Growing Fruit per E-Mail zu allen Themen über den Anbau nordamerikanischer Pawpaws abonniert. Im Sommer und Herbst besuche ich dieses Forum mehrmals täglich, um den ständigen Strom neuer Beiträge in diesen Themen zu lesen, aber außerhalb dieser Monate sind es hauptsächlich die E-Mail-Benachrichtigungen zu diesen Themen, die mich engagiert halten.
- Personen, die das Web nur sporadisch nutzen. Oft wird angenommen, dass, wenn Leute das Web nicht regelmäßig nutzen, dies irgendwie mit der digitalen Kluft zusammenhängt, aber oft ist dies nicht der Fall. Es gibt viele Leute, die sowohl hochintelligent als auch technisch versiert sind, aber aufgrund ihrer Position an der Spitze ihres Fachgebiets davon abgeschirmt sind, das Web regelmäßig nutzen zu müssen. Ein reales Beispiel hierfür ist jemand wie Donald Knuth, der das Web nicht regelmäßig nutzt, obwohl er einer der führenden lebenden Informatiker ist. Jedes Fachgebiet hat solche Leute, und sie dazu zu bringen, ihr Wissen zu teilen, ist von unschätzbarem Wert. Nach meiner Erfahrung werden diese Leute wahrscheinlich keine regelmäßigen Beiträge zu einem Forum leisten, aber wenn jemand ihnen sagt, dass es ein Thema gibt, das sie interessieren würde, abonnieren sie es oft per E-Mail und tragen zu diesen spezifischen Themen bei.
Das große Bild ist, dass die Verbesserung der Verarbeitung eingehender E-Mails nicht nur die Beteiligung von Personen erhöhen sollte, die bereits regelmäßige aktive Discourse-Beitragsleister sind, sondern auch viele Gemeinschaften entblocken sollte, die andernfalls gerne auf die Plattform migrieren würden, und zudem hochrangige Inhalte von Personen einholen sollte, die andernfalls nicht beitragen würden.
Die FWD:Everyone E-Mail-Verarbeitungs-API
Die FWD:Everyone E-Mail-Verarbeitungs-API tut zwei Dinge:
- Entfernt präzise Signaturen und Antworten aus jeder E-Mail-Nachricht, während gleichzeitig Inline-Antworten auf zitierten Texten ermöglicht werden.
- Nimmt das extrem komplexe HTML-Markup, das von E-Mail-Clients generiert wird, und normalisiert dieses Markup auf die ~12 HTML-Tags, die typischerweise von nutzergenerierten Inhaltssites erlaubt sind – und zwar unter größtmöglicher Wahrung der Absicht des Autors.
Ich werde beides im Detail erläutern, aber zunächst hier ein Video, das ich erstellt habe und das das Problem durch die Darstellung realer E-Mail-Threads erklärt: https://www.youtube.com/watch?v=nPb3NQlz6V4
Entfernen von Signaturen und Antworten
Die FWD:Everyone E-Mail-Verarbeitungs-API funktioniert sowohl bei Klartext- als auch bei HTML-E-Mails mit gleicher Genauigkeit. Die API nutzt bevorzugt den HTML-Teil der Nachricht, wenn verfügbar, weil:
- Die vom Autor gewählten HTML-Formatierungsfunktionen (wie Fett, Kursiv, Zitate, Code-Snippets usw.) ein wesentlicher Teil der Botschaft des Autors sind, genauso wichtig wie der Text selbst.
- Wenn E-Mail-Clients die HTML-Version einer Nachricht in die Klartext-Version umwandeln, geschieht dies oft fehlerhaft. Zum Beispiel versuchen E-Mail-Clients oft gar nicht, HTML-Funktionen wie Aufzählungslisten im Klartext darzustellen, und oft fehlt der Text innerhalb von HTML-Formatierungselementen vollständig.
Natürlich bevorzugen einige Nutzer das Senden von Klartext-E-Mails; daher müssen Klartext-only-E-Mails mit gleicher Genauigkeit Signaturen und Antworten entfernen.
Die FWD:Everyone E-Mail-Verarbeitungs-API erledigt dies, einschließlich der korrekten Handhabung von Inline-Antworten in sowohl Klartext- als auch HTML-E-Mails.
In Bezug auf die Genauigkeit gibt es zwei Arten von Fehlern, die in jeder E-Mail-Verarbeitungsbibliothek beim Entfernen von Signaturen und Antworten auftreten können:
- Falsch-positive Ergebnisse – Wenn Text, der in der Nachricht enthalten sein soll, fälschlicherweise ausgeschlossen wird.
- Falsch-negative Ergebnisse – Wenn Text, der nicht in der Nachricht enthalten sein soll, fälschlicherweise eingeschlossen wird.
Es ist schwierig, genaue Genauigkeitsstatistiken anzugeben, da verschiedene Discourse-Gemeinschaften (kleingeschrieben) E-Mails so unterschiedlich nutzen. Aber im Vergleich zur aktuellen Verarbeitungslösung von Discourse könnte eine realistische Erwartung sein:
- 100-mal weniger falsch-positive Ergebnisse beim Entfernen von Signaturen und Antworten
- 10-mal weniger falsch-negative Ergebnisse beim Entfernen von Antworten
- 1- bis 10-mal weniger falsch-negative Ergebnisse beim Entfernen von Signaturen – wahrscheinlich besser, aber nicht eine ganze Größenordnung besser.
Zum Kontext: Falsch-positive Ergebnisse sind im Allgemeinen viel schlimmer als falsch-negative Ergebnisse, da sie das, was die Person geschrieben hat, falsch darstellen. Aber falsch-negative Ergebnisse sind ebenfalls sehr schlecht, da sie den Poster (und alle anderen im Forum) bestenfalls unprofessionell und schlimmstenfalls schlicht dumm aussehen lassen.
Der Ansatz, den FWD:Everyone verfolgt, besteht darin, auf Tricks zum Entfernen von Signaturen zu verzichten, die zu falsch-positiven Ergebnissen führen können; die vermeintliche Zunahme an falsch-negativen Ergebnissen, die dies führen würde, wird dann weitgehend durch die Tatsache ausgeglichen, dass eine enorme Menge an Arbeit in die legitime Funktionsweise des Algorithmus investiert wurde, ohne Abkürzungen zu nehmen.
Der Hauptgrund, warum die FWD:Everyone E-Mail-Verarbeitungs-API im Allgemeinen viel genauer sein wird als die aktuelle Lösung von Discourse, ist, dass unsere API so konzipiert wurde, dass sie ganze E-Mail-Threads verarbeitet, was ein weitaus schwierigeres Problem ist als die Verarbeitung von einzelnen Antwort-funktion-Beiträgen. Das Endergebnis ist, dass unser Produkt stark überengineered ist, zumindest im Vergleich sowohl zu den Bedürfnissen von Discourse als auch zur bestehenden Vorarbeit.
Normalisierung von HTML-Markup
Damit Antworten, die per E-Mail eingereicht werden (und importierte E-Mail-Threads), genauso aussehen wie jeder andere nutzergenerierte Inhalt, müssen sie letztendlich mit derselben Teilmenge von HTML gerendert werden, die erlaubt ist, wenn Nutzer über die Website antworten.
Dies ist überraschend kompliziert.
E-Mails, die in E-Mail-Clients wie Gmail und Outlook verfasst werden, werden unter Verwendung einer Kombination aus ~50 HTML-Tags, ~25 HTML-Attributen und ~175 CSS-Stilen kodiert. Darüber hinaus ist dieses Markup oft stark verschleiert; man könnte erwarten, dass ein Absatz Text so aussieht:
<p>Einiger Text!</p>
Stattdessen werden selbst einfache Absätze oft mit tief verschachtelten und völlig unsinnigen Kombinationen von Divs, Spans, Tabellen, Listen usw. kodiert. Dies ist die Hauptquelle der Komplexität sowohl beim Entfernen von Antworten als auch beim Normalisieren von Markup.
Unabhängig davon wird jede Nachricht nach der Verarbeitung nur mit folgendem Markup gerendert:
Erlaubte Block-Elemente: <p>, <ul>, <ol>, <li>, <blockquote>, <pre>
Erlaubte Inline-Elemente: <code>, <a>, <b>, <i>, <u>, <s>, <span>
Hinweise:
- Die einzigen erlaubten Attribute (außer bei
<a>-Tags) sindstyleunddir. - Das einzige erlaubte Inline-Style ist
font-weight. <a>-Tags können auch die Attributehref,rel,titleundtargethaben.<span>-Elemente werden nur in begrenzten Fällen verwendet, um sicherzustellen, dass Schriftstärken korrekt kaskadieren. Daher werden sie immer mit einem Inline-font-weightverwendet.- In Zukunft wird auch das
<img>-Tag verwendet, um Inline-Bilder anzuzeigen.
Das Rendern von Beiträgen in dieser begrenzten Teilmenge von HTML ermöglicht es, dass jeder per E-Mail eingereichte Beitrag leicht mit exakt derselben Typografie wie Beiträge, die über die Web-Oberfläche eingereicht wurden, gerendert werden kann.
Dies alles wird unter größtmöglicher Wahrung der Absicht des Autors durchgeführt, während gleichzeitig sichergestellt wird, dass sie keine Dinge tun können, wie das Einfügen von Dutzenden unnötiger Zeilenumbrüche zwischen Absätzen.
Siehe auch: Der Abschnitt „CSS-Styling“ unten.
Sprachunterstützung
EmailReplyTrimmer bietet derzeit vollständige oder teilweise Unterstützung für 13 Sprachen:
Englisch, Norwegisch, Französisch, Deutsch, Portugiesisch, Spanisch, Italienisch, Niederländisch, Schwedisch, Chinesisch, Russisch, Polnisch, Ukrainisch
Im Gegensatz dazu unterstützt die FWD:Everyone E-Mail-Verarbeitungs-API derzeit über 30 Sprachen, einschließlich jeder Sprache, die Discourse derzeit unterstützt:
Englisch, Spanisch, Portugiesisch, Katalanisch, Niederländisch, Französisch, Deutsch, Italienisch, Norwegisch, Dänisch, Schwedisch, Finnisch, Russisch, Polnisch, Ukrainisch, Türkisch, Tschechisch, Rumänisch, Ungarisch, Hebräisch, Arabisch, Persisch, Chinesisch, Japanisch, Koreanisch, Hindi, Indonesisch, Thai, Filipino, Afrikaans
Die FWD:Everyone E-Mail-Verarbeitungs-API unterstützt vollständig RTL-Sprachen. Das bedeutet, dass nicht nur Text in Sprachen wie Arabisch korrekt von rechts nach links fließt, sondern auch die entsprechenden Attribute auf das HTML-Markup angewendet werden, damit Funktionen wie Aufzählungspunkte auf der richtigen Seite der Seite gerendert werden.
Die API funktioniert manchmal auch in zusätzlichen Sprachen, abhängig vom verwendeten E-Mail-Client, aber der offiziell unterstützte Sprachumfang wird mindestens mit Gmail, Outlook und Apple Mail getestet. Weniger verbreitete E-Mail-Clients werden explizit in den Sprachen getestet, in denen sie die höchste Nutzung haben. Und da die API gegen Tausende von E-Mail-Threads aus öffentlichen Mailinglisten getestet wird, gibt es unzählige Korrekturen für reales, erraticches Verhalten unbekannter Herkunft.
Hinweis: Die Unterstützung einer Vielzahl von Sprachen ist wichtig, nicht nur für die Anzeige von Text in diesen Sprachen. Es ist sehr üblich, dass Leute Text auf Englisch schreiben, aber ihren E-Mail-Client so konfiguriert haben, dass er z. B. Hebräisch verwendet. In solchen Fällen erfordert die korrekte Verarbeitung einer englischen Antwort nicht nur die vollständige Unterstützung von Hebräisch, sondern auch die allgemeine Unterstützung von Rechts-nach-Links-Sprachen.
Die Unterstützung von Sprachen aus einer Vielzahl von Sprachfamilien hilft auch, sicherzustellen, dass Unicode korrekt verarbeitet und gespeichert wird, anstatt auf Arten, die in Zukunft Probleme verursachen könnten, wenn die Unterstützung für mehr nicht-westliche Sprachen hinzugefügt wird.
CSS-Styling
Wie oben erwähnt, ist eine Schlüsselstärke unserer API ihre Fähigkeit, HTML-Markup auf eine durchdachte und logische Weise zu normalisieren. Dieser Normalisierungsprozess ist darauf ausgelegt, Text für Lesbarkeit und Zugänglichkeit zu optimieren, während gleichzeitig die ursprüngliche Absicht des Autors größtmöglich gewahrt bleibt.
Daher erscheint alle Text nur innerhalb von Inline- oder Block-Elementen (kein frei schwebender Text), und alle Inline-Elemente erscheinen nur innerhalb von Block-Elementen. Dies macht es einfach, Text zu stylen, z. B. um sicherzustellen, dass verschiedene Elemente die richtige Menge an Leerzeichen zwischen sich haben.
Als Beispiel, wie dies wertvoll ist, erlauben E-Mail-Clients Nutzern, alberne Dinge zu tun, wie das Einfügen einer Aufzählungsliste direkt vor oder nach einer Textzeile, ohne Zeilenumbruch dazwischen. Der (stark vereinfachte) Code, der von einem E-Mail-Client dabei generiert wird, könnte so aussehen:
<div>
Einiger Text
<div> </div>
<span> • Ein Aufzählungspunkt</span>
<div> </div>
Noch mehr Text
</div>
Die FWD:Everyone E-Mail-Verarbeitungs-API würde das obige Markup dann normalisieren, so dass es stattdessen so aussieht:
<p>Einiger Text</p>
<ul>
<li>Ein Aufzählungspunkt</li>
</ul>
<p>Noch mehr Text</p>
Dieses normalisierte Markup ist leicht zu verstehen und zu stylen, und visuell gibt es jetzt auch Zeilenumbrüche vor und nach der Aufzählungsliste. Solche Affordanzen machen den Text besser aussehend und leichter lesbar, während die Absicht des Autors gewahrt bleibt. Diese Arten von Nutzeraffordanzen stellen sicher, dass großartiger Inhalt, der per E-Mail eingereicht wird, konsistent sozialen Status verleiht, anstatt ihn zu untergraben.
Das vereinfachte, normalisierte Markup, das von unserer API generiert wird, stellt auch sicher, dass Designer und Entwickler beim Nachdenken darüber, wie Text gestylt werden soll, nur über die Ausgabe nachdenken müssen, die die API erlaubt, anstatt darüber, wie die ursprüngliche E-Mail formatiert sein könnte. Und da die erlaubte Ausgabe der API nahezu identisch mit dem ist, was der Discourse-Web-Client erlaubt, sollte dies fast eine Plug-and-Play-Lösung sein.
Vorgeschlagene Integration
Die Funktion „Antwort per E-Mail“ würde als Plugin in Discourse integriert, das dann standardmäßig für alle gehosteten Discourse-Instanzen aktiviert werden könnte.
Der bestehende Code zur E-Mail-Verarbeitung würde für Discourse-Instanzen verwendet, die dieses Plugin nicht aktiviert haben.
Zusätzlich würde im Falle einer vorübergehenden Nichtverfügbarkeit der FWD:Everyone E-Mail-Verarbeitungs-API jede eingehende Nachricht mit dem bestehenden Code zur E-Mail-Verarbeitung verarbeitet. Sobald die API wieder online ist, könnten alle Nachrichten, die seit dem Posten nicht über die Web-Oberfläche bearbeitet wurden, dann erneut von der API verarbeitet werden.
Das Plugin könnte auch für selbstgehostete Discourse-Instanzen verfügbar gemacht werden, um es optional zu aktivieren.
Für Gruppen, die von bestehenden Mailinglisten zu Discourse migrieren, könnte jeder E-Mail-Thread in der Mailingliste ebenfalls über die API verarbeitet werden, aber dies würde wahrscheinlich in die bestehenden Migrations-Skripte und -Prozesse von Discourse integriert werden, anstatt über ein Plugin.[2]
Testen der API
Die API ist für jedermann vollständig verfügbar, jedoch mit einem sehr niedrigen Rate-Limit für nicht-authentifizierte Nutzer.
Für diejenigen mit Gmail-Konten sind die einfachsten Möglichkeiten, die API zu testen:
- Gehen Sie zu https://www.prettyfwd.com und installieren Sie das G Suite-Add-on.
- Gehen Sie zu https://api-demo.fwdeveryone.com und verwenden Sie das clientseitige OAuth, um mit der API zu spielen.
Wichtige Unterschiede zwischen diesen beiden webbasierten Tools und der tatsächlichen API sind, dass erstere:
- Threads nicht verarbeiten, die Nachrichten enthalten, die mit HTML-Tabellen gestylt sind
- Antworten auf die erste Nachricht in einem Thread nicht entfernen. (Zum Beispiel, wenn ein Thread über 100 Nachrichten hat, sodass Gmail ihn in mehrere Threads aufteilt.)
Um die API direkt über Code zu testen, gibt es Starter-Skripte für Python und Ruby:
Und hier ist die relevante Dokumentation, einschließlich bekannter Probleme und der Produkt-Roadmap:
[1] Viewing American class divisions through Facebook and MySpace.
[2] Beim Massimport von Inhalten aus einer bestehenden Mailingliste lohnt es sich, zunächst einen kurzen Plausibilitätscheck an einigen Threads durchzuführen, um sicherzustellen, dass sie korrekt verarbeitet werden. Einige Gruppen werden mit nahezu perfekter Genauigkeit verarbeitet, wie sie sind, aber andere können stark von ein paar Stunden präventiver Arbeit profitieren. Zum Beispiel erfordert einige Mailinglisten-Software etwas benutzerdefinierten Code für jede Liste, um jeglichen Text, der an den unteren Rand jeder Nachricht angehängt wird, abzuschneiden, während dies bei anderer Mailinglisten-Software auf eine vorhersehbare Weise erfolgen kann, die für jede Liste funktioniert, die auf dieser Plattform gehostet wird. Aufgrund potenzieller Probleme wie diesem sollte der Massimport-Prozess vorzugsweise im Rahmen einer überwachten Migration ausgeführt werden, anstatt über ein Plugin.