Newsletter Archiv - technische Diskussion

**tril** · 10.02.2012, 21:41

Ich habe folgendes Problem, für die nächste Version ist ein "persistentes" Newsletter Archiv geplant. Also versendeten Newsletter sollen persistent gespeichert werden, so dass auch langfristig alte Newsletter weiterhin zur Verfügung stehen. Zumindest ist das meine Idee, aber ist das notwendig? Das möchte ich euch, die "Hauptnutzer" von Avisota fragen

Aktuell gibt es eigentlich 3 grundlegende Varianten die ich sehe:

Variante 1: Nur dynamisch, keine Persistenz
Eigentlich ändert sich lediglich ein DB Flag (versendet), die Newsletter verschwinden aus der Newsletterverwaltung und kommen in das Newsletterarchiv. Beim Abrufen wird der Newsletter dann immer live gerendert. Alle Änderungen an Templates wirken sich auch darauf aus.
Pro:
- geringster Aufwand
- unterschiedliche Ausgaben weiterhin möglich (z.B. Rendern im Reader Modul oder mit einem anderen Template)
Kontra:
- keine wirkliche Archivierung von Altbeständen, da diese nicht vor Löschvorgängen geschützt sind.

Variante 2: Relevante Newsletterdaten speichern
Alles was zum generieren des Newsletters gebraucht wird, wird gespeichert. Das betrifft die Datenbankinformation (Content), referenzierte Bilder, Template, Stylesheet zum Zeitpunkt des Versendens.
Pro:
- unterschiedliche Ausgaben weiterhin möglich (z.B. Rendern im Reader Modul oder mit einem anderen Template)
Kontra:
- Relativ große Redundanz an Daten (ließe sich durch intelligentes Archivierungssystem kompensieren)
- Nachträgliche Korrekturen begrenzt möglich
- Kaum Vorteile gegenüber Variante 1

Variante 3: Generierten Newsletter speichern
Der Newsletter wird generiert und gespeichert. Dies muss allerdings ziemlich atomar erfolgen, damit es zumindest teilweise möglich ist, nur Teile eines Newsletter weiterhin darzustellen (z.B. über das Reader Modul).
Pro:
- Absoluter Erhalt von Altdaten zum Zeitpunkt des Versendens.
Kontra:
- Relativ große Redundanz an Daten (ließe sich durch intelligentes Archivierungssystem kompensieren)
- Nachträgliche Korrekturen überhaupt nicht möglich
- Alternative Ausgabe nur teilweise möglich (z.B. Inhalt im Reader Modul ausgeben, allerdings mit dem alten Template oder Möglichkeit der "Aktualisierung")
- Sehr aufwendig in der Implementierung

Ich persönlich tendiere eigentlich schon zu Variante 1, Variante 2 und 3 haben auch Speichertechnisch erhebliche Nachteile.

Rechenbeispiel, Variante 1:
Es entsteht kein Mehrverbrauch.
Mehrbedarf an Ressourcen pro versendetem Newsletter: 0 B

Rechenbeispiel, Variante 2:
Ein Newsletter besteht durchschnittlich aus 1 kB Informationen (DB) und 300 kB Ressourcen (Bilder, CSS). Für jeden Newsletter muss dieser Bestand zusätzlich gespeichert werden (ich gehe davon aus, dass die Ressourcen für jeden Newsletter einzigartig sind - Worst Case). Da die Informationen über den Inhalt "abstrakt" vorliegen, ist es möglich sowohl personalisierte als auch unpersonalisierte Newsletter zu generieren.
Mehrbedarf an Ressourcen pro versendetem Newsletter: 1 kB + 300 kB = 301 kB

Rechenbeispiel, Variante 3 A:
Worst Case: Der Newsletter ist extrem personalisiert, bedeutet quasi ich muss nicht nur pro Newsletter, sondern auch pro Empfänger den Newsletter speichern. Da ein generierter Newsletter aus HTML und nicht aus abstrakten Informationen besteht, ist der Speicherverbrauch potentiell größer. Ich nehme einfach mal an, ein Newsletter in HTML Form bedarf 15 kB HTML und 300 kB Ressourcen.
Mehrbedarf an Ressourcen pro versendetem Newsletter: Empfängeranzahl * 15 kB + 300 kB =(bei 1000 Empfänger) 15300kB = ~15MB

Rechenbeispiel, Variante 3 B:
Das Caching ist intelligenter und speichert Content Element für Content Element ab. Von den 15 kB sind dann nur noch 3 kB personalisiert (also pro Benutzer) und 12 kB statisch (für alle gleich). Hier muss aber wirklich so feingranular wie möglich alles gespeichert werden.
Mehrbedarf an Ressourcen pro versendetem Newsletter: Empfängeranzahl * 3 kB + 12 kB + 300 kB =(bei 1000 Empfänger) 3312 kB = ~3 MB

Rechenbeispiel, Variante 3 C:
Der Newsletter ist nicht personalisiert, also für alle gleich.
Mehrbedarf an Ressourcen pro versendetem Newsletter: 15 kB + 300 kB =(bei 1000 Empfänger) 315 kB

Und jetzt das ganze mal aufs Jahr hochgerechnet:
1 Newsletter pro Monat bei
Variante 1: 0
Variante 2: 3.612 kB = ~ 3,5 MB
Variante 3 A: 183.600 kB = ~183 MB
Variante 3 B: 39.744 kB = ~40 MB
Variante 3 C: 3.780 = ~ 3,5 MB

1 Newsletter pro Woche bei
Variante 1: 0
Variante 2: 14.448 kB = ~ 14 MB
Variante 3 A: 734.400 kB = ~734 MB
Variante 3 B: 158.976 kB = ~158 MB
Variante 3 C: 15.120 = ~ 15 MB

1 Newsletter pro Werktag (5 Tage die Woche) bei
Variante 1: 0
Variante 2: 72.240 kB = ~ 72 MB
Variante 3 A: 3.672.000 kB = ~3.672 MB = ~3,5 GB (!!!)
Variante 3 B: 794.880 kB = ~794 MB
Variante 3 C: 75.600 = ~ 75,5 MB

Um Variante 3 etwas zu relativieren, wahrscheinlich ist (bei kleverer Programmierung) das Variante 3 B ziemlich häufig der Fall sein wird. Variante 3 A ist sehr unwahrscheinlich.

Die Zahlenwerte stammen übrigens von einem Newsletter, den ich mal umgesetzt habe, allerdings ist mit mehr verbrauch zu rechnen, weil die Ressourcenverbrauchsangaben lediglich von einen "kleinen" Testnewsletter stammen.

---

Was sagt Ihr, habe ich irgendwas übersehen? Gibt es bessere Lösungen? Was wird benötigt? Ist der (deutliche) Mehraufwand von Variante 2+3 es überhaupt wert? Ihr seid gefragt

**backbone** · 10.02.2012, 22:47

Also ich find Variante 1 schon am sinnvollsten. Evtl. mit Softlock von Edit/Delete Funktionen und standardmäßig ausgeblendet im Listing oder so.

Bei Variante 2 & 3 finde ich, dass Speicherplatz kein Kontra-Argument ist... Plattenplatz ist billig und der GB den du übers Jahr mit 1000 Empfängern generierst kostet dich nicht mal 50 Cent...

**Psi** · 11.02.2012, 10:22

Moin Tril,

ich denke Variante 1 reicht (bin aber kein exzessiver Avisotanutzer).
Wenn ich mich in unsere Kunden versetze geht es primär um Strukturierung und nicht um ein exaktes Abbild eines Newsletters. Außerdem hat man den ja auch in seinem Postfach

**Ynda** · 15.02.2012, 11:58

Hallo zusammen,

ich halte die Archivdiskussion zum jetzigen Zeitpunkt (wo es noch dringendere Reparaturen und Anpassungen gibt) für zu früh. Die Variante 1 ist durchaus akzeptabel.
Man kann das Archiv dahingehend selbst steuern, indem man bei Templateänderungen einfach eine neue Kategorie aufmacht und ein neues Template zuordnet. CSS sollte wegen der größtmöglichen Kompatibilität sowieso inline sein und fällt damit als externe Resource weg. Bilder, solange nicht gelöscht stehen dauerhaft zur Verfügung. Statische Elemente bleiben langfristig erhalten, lediglich bei dynamische Elemente wie z. Bsp. Events sehe ich ein kleines Problem. Die werden wahrscheinlich ein Verfallsdatum haben und irgendwann verschwinden. (Btw. Events sollten nicht nach dem Startdatum sondern nach dem Endedatum zur Auswahl angeboten werden. Ich denke da an länger laufende Events wie Messen)
Ich bin auch der Meinung, dass bei absoluter und evtl. auch rechtlicher Notwendigkeit eines Archives aktuell andere Systeme oder Provider zum Einsatz kommen. Wir sollten Avisota in erster Linie mal funktional und funktionierend halten und nicht mit zu vielen Zusatzfeatures überfrachten.
Diese Diskussion würde ich zu einem späteren Zeitpunkt führen.

Gruß Andreas

**tril** · 15.02.2012, 13:18

Hallo Andreas,

"genügt im Moment" ist leider eine sehr schwammige Aussage, da die nächste Version deutliche Datenbankveränderungen erfahren wird und ich möchte dies dann auch berücksichtigt haben. Ich denke eigentlich auch, dass grundlegend Variante 1 immer ausreichen sollte. Allerdings habe ich mir halt auch über eine statische Archivierung Gedanken gemacht und dazu wollte ich gerne die Meinung der Community hören.

CSS sollte wegen der größtmöglichen Kompatibilität sowieso inline sein und fällt damit als externe Resource weg. Bilder, solange nicht gelöscht stehen dauerhaft zur Verfügung.

Nein die fallen nicht wag, die sind genau so wie Bilder zu betrachten. Da in Variante 1 überhaupt keine Ressourcen statisch gespeichert werden, wirkt sich natürlich auch das löschen einer einzelnen CSS Datei genau so aus, wie das löschen eines Bildes.
Im versendeten NL werden alle Ressourcen (CSS und Bilder) aktuell ja sogar eingebettet und gar nicht verlinkt. Von daher ist das Problem bei der generierten E-Mail aktuell sowieso nicht vorhanden. Es geht um das innerhalb von Contao verwaltete Archiv.

Wir sollten Avisota in erster Linie mal funktional und funktionierend halten und nicht mit zu vielen Zusatzfeatures überfrachten.

Trotzdem müssen neue Funktionen gebaut werden und aktuell ist (bei mir) der beste Zeitpunkt. Dies wird nur eines von vielen Funktionen sein, die kommen werden.

Diese Diskussion würde ich zu einem späteren Zeitpunkt führen.

Die Umfrage läuft beabsichtigt 14 Tage. Bis dahin habt Ihr Zeit

**Ynda** · 15.02.2012, 17:14

Hallo Tristan,

das wusste ich nicht. Unter diesen Umständen führen wir die Diskussion eben jetzt.

Die 1. Frage, die sich mir stellt ist: Zu welchem Zweck benötige ich überhaupt eine Archivierung?
Die 2. Frage, wie exakt und revisionssicher muss dieses Archiv beschaffen sein?

Unter einem Archiv, verstehe ich "Wird so wie es ist eingepackt und in den Keller gelegt"

.

Ich kenne die revisionssichere Archivierung aus dem Umfeld geschäftlicher E-Mails. Hier benötige ich zwingend eine entsprechend zertifizierte Software.
Wir benutzten MailStoreServer. Auch hier wird darauf geachtet, dass keine Redundanzen abgelegt werden. Jedes Bild und jede PDF-Datei, egal zu welcher E-Mail die gehören wird nur einmal gespeichert.

Mein Ansatz wäre, den Mechanismus der Online-Ansicht zu verwenden, um den HTML-Code zu generieren. Alle darin befindlichen Resourcen kommen in ein Unterverzeichnis und werden (z.Bsp.: per MD5) umbenannt. Somit landet hier jede externe Datei nur einmal, da einmalig. Links im HTML-Code umschreiben und fertig. Noch ein Index dazu und fertig ist das Archiv im Sinne von, kann jederzeit nachvollzogen werden, was mal rausgegangen ist. Für die normale Online-Ansicht im Sinne von, "kann meine Mail nicht entziffern", gibt es ja schon einen Mechanismus.
Revisionssicher muss das ganze dann nur noch signiert verpackt werden. Aber wozu, frag ich mich - kaufmännisch relevante Verträge werden wohl kaum per Newsletter verschickt.

Wer archivieren muss, aus welchem Grund auch immer sorgt für den notwendigen Plattenplatz. Platzverschendung zu vermeiden ist trotzdem immer gut.
Eine Archivmail in jeden Verteiler aufzunehmen, die dann im eigenen E-Mail-Archiv-System landet (so machen wir das) ist auch eine Variante, hat aber mit Avisota nichts zu tun.

Was mich nur immer wieder ärgert in unserer ach so an Feature überladenen Gesellschaft: Wir haben ne Menge Zeugs von dem aber nur die Hälfte zufriedenstellend funktioniert und mit der anderen Hälfte verbringen wir Stunden und Tage sie zum Laufen zu bewegen. Ich würde mir einfach nur wünschen, dass die aktuell vorhadenen Funktionen funktionieren. Ich möchte einmal einen Avisota-Newsletter aufsetzen ohne an der einen oder anderen Ecke nach Lösungen suchen zu müssen. Nichts für ungut, das Teil ist super und allein schon dafür werden sicher einige Leute zu Contao wechseln, aber weniger Neues dafür mehr funktionierendes Altes wäre nicht schlecht.

Gruß Andreas