Tag 3 Relative Wiedervorlage - ralfw/emailwiedervorlage GitHub Wiki

Der Dienst empfängt Einplanungen für Wiedervorlagen und verschickt Wiedervorlagen. Der Roundtrip funktioniert. Da sollte der nächste Schritt sein, Wiedervorlagen auch termingerecht zu versenden. Dafür muss der Terminwunsch, der in der Email-Adresse codiert ist, interpretiert werden.

Für dieses Inkrement beschränke ich die Terminwünsche auf relative Terminangaben bzw. Countdowns. Sie sollen die Form haben:

Terminwunsch ::= "in" Countdown Zeitraum "@wiedervorlage.cc".
Countdown ::= Ziffer+.
Zeitraum ::= "minute" | "minuten" | "stunde" | "stunden" | "tag" | "tagen" | 
             "woche" | "wochen" | "monat" | "monaten" | "jahr" | "jahren".

Leerzeichen sind zwischen den Elementen des Terminwunsches nicht erlaubt.

Beispiele:

[email protected]
in30stunden@...
in1monaten@...
in7jahr@...

Grammatikalisch falsche Terminwünsche wie in7jahr@... sind syntaktisch erlaubt.

Falls ein Terminwunsch syntaktisch nicht korrekt ist, wird eine Email mit Fehlermeldung an den Absender geschickt.

Die Berechnung des Wiedervorlagetermins erfolgt durch schlichte Addition des Countdowns auf die Datum/Uhrzeit beim Server. Wer um 23:05h eine Einplanung mit in1tag@... schickt, bekommt am nächsten Tag ebenfalls um 23:05h die Wiedervorlage.

Derzeit läuft der Service ja nur lokal. Und er läuft auch nicht permanent, sondern wird von Hand bzw. periodisch gestartet. Das bedeutet:

Wenn der Service das nächste Mal läuft, versendet er alle bis dahin fälligen Wiedervorlagen auf einmal.
Der Wiedervorlagetermin wird genau berechnet. Aber die Wiedervorlage erfolgt nicht verlässlich zu diesem Zeitpunkt. Der Service hat vielmehr eine Auflösung entsprechend der Periode seiner Fälligkeitsprüfung. Prüft der Service nur alle 5 Minuten auf fällige Wiedervorlagen, dann wird auch nur 5-Minuten-genau vorlegt, selbst wenn minutengenau eingeplant wurde. Ich denke, eine Wiedervorlageauflösung von 15 Minuten sollte ausreichen.
Ebenso ist die zeitliche Nähe, in der eine Wiedervorlage liegen kann, durch die Periodizität des Service begrenzt. Wenn der Serice nur alle 10 Minuten Einplanungen abfragt, kann nicht verlässlich mit einem kürzeren Countdown eingeplant werden. Aber auch hier denke ich, das eine Periode von 15 Minuten ausreichen sollte.

Die Speicherung der Wiedervorlagetermine kann in diesem Inkrement lokal geschehen. Das Dateisystem reicht als Persistenzmedium für den persönlichen Gebrauch völlig aus.

Allerdings ist damit die Wiedervorlage darauf angewiesen, dass der persönliche Rechner läuft. Falls Wiedervorlagen auch gemacht werden sollen, wenn das nicht der Fall ist, muss der Service in die Cloud wandern (z.B. ironWorker) und damit auch das Persistenzmedium wechseln (z.B. Parse Objects, MongoDB).

Teilinkremente

Nur einen fixen Countdown erkennen und in 15 Sekunden wieder vorlegen
Minuten-Zeitraum erkennen
Alle Zeiträume erkennen
Fehlerhaften Countdown per Email melden
Logging