Hallo,
dass so etwas fehlt, geht mir schon lange durch den Kopf. Mal sehen wann es wirklich nutzbar ist:
Damit soll SMTP/IMAP (auf jeden Fall für den Mail User Agent) nicht mehr nötig sein, und es wird http+JSON verwendet.
Was denkt ihr dazu?
Gruß, Thomas
Hi,
On Thu, Nov 14, 2019 at 12:37:47PM +0100, Thomas Güttler guettliml@thomas-guettler.de wrote:
Hallo,
dass so etwas fehlt, geht mir schon lange durch den Kopf. Mal sehen wann es wirklich nutzbar ist:
https://jmap.io/Damit soll SMTP/IMAP (auf jeden Fall für den Mail User Agent) nicht mehr nötig sein, und es wird http+JSON verwendet.
Was denkt ihr dazu?
Hm. OK, man kann also auf seine Emails via HTTPS zugreifen, wenn mal irgendwo eine Firewall IMAP verhindert. Nur geht das in fast allen relevanten Fällen sowieso auch über ein entsprechendes Webfrontend, der Mehrwert ist also überschaubar.
Gut, die Mails werden evtl etwas effizienter übertragen und ein paar Operationen gehen "besser" (Folder umbenennen z.B. bleibt effizient, weil nicht ein ganzer Ordner neu synchronisiert werden muss). Realer Mehrwert vermutlich in den meisten Fällen überschaubar (ich habe z.B. noch fast nie irgendwelche Folder umbenannt), hin und wieder aber ganz nett.
Aber eigentlich wird das falsche Problem gelöst. Wenn die Mail-Provider mal durchgehend problemlos IMAP+SMTP unterstützen würden, wäre es völlig zweitrangig, welchen Email-Client man so nutzt und es würde schlicht immer funktionieren. Ich z.B. verwende auf dem Desktop mutt und auf dem Handy k9-mail (gegen 2 verschiedene IMAP-Mailboxen), und da funktioniert schlicht alles in allen relevanten Szenarien stressfrei, weil eben alle IMAP reden. Könnte es vereinzelt schneller gehen? Sicher. Aber es ist halt auch keine komplette Katastrophe. Und die ganzen "Batterie sparen"-Themen kann ich mittlerweile nur noch zum Teil nachvollziehen. Ist halt die Frage, ob man rund-um-die-Uhr-push-Mail haben will oder ob man z.B. auch mit "einmal die Stunde die Mails abrufen reicht auch" leben kann, oder gar mit "on demand reicht völlig". Gut, gibt dann so Randfälle wie "ich hab gerade keinen Empfang und kann jetzt nicht die Mails abrufen, und vorhin in der Straßenbahn hab ich nicht drangedacht, da hätte es geklappt". Aber dafür ist Mail halt auch ein offline-Medium und kein Live-Chat.
Gruß, Thomas
Ciao, Thomas
https://jmap.io/
Was denkt ihr dazu?
Die Labels sind ein wichtiger Schritt. Durch Ordner ist Imap bei vielen Power-Usern tot.
Die Push-Nachrichten sind die zweite Funktion, die bei IMAP bisher zu unzuverlässig und zu teurer waren.
Also: Gute Sache, und wenn es nur ein paar gute Clients können und man es sich selbst installieren kann, prima. Ich frage mich, ob das die wesentlichen Probleme von Mail löst. Spam, doofe Anhänge, Zitierkatastrophen, schlecht ausgewählte Empfänger. Messenger sind da viel weiter, und vielleicht sollte man eher ein Matrix/Riot auf Mailempfang bringen als in Mailserver die Funktionen von Matrix zu bauen.
Thomas
Guten Morgen, klingt interesannt. Leider kenne ich die Funktionsweise von SMTP/IMAP nicht um das tatsächlich vergleichen zu können. Würde mich aber freuen wenn diese Diskussion hier nicht im Sand verläuft und ein paar nützliche Informationen bekannt werden würden.
Gruß Stefan
Am Do., 14. Nov. 2019 um 12:37 Uhr schrieb Thomas Güttler < guettliml@thomas-guettler.de>:
Hallo,
dass so etwas fehlt, geht mir schon lange durch den Kopf. Mal sehen wann es wirklich nutzbar ist:
https://jmap.io/Damit soll SMTP/IMAP (auf jeden Fall für den Mail User Agent) nicht mehr nötig sein, und es wird http+JSON verwendet.
Was denkt ihr dazu?
Gruß, Thomas
-- Thomas Guettler http://www.thomas-guettler.de/ I am looking for feedback: https://github.com/guettli/programming-guidelines
Guten Morgen;
alle: Danke für den Link. Hatte ich noch nicht auf dem Schirm. Finde ich... interessant. Auch wenn spontan die erste Frage natürlich ist: Ist HTTP+JSON das Werkzeug der Wahl für *jedes* Problem? Momentan scheint mir das zu einer zusätzlichen Layer auf dem bekannten TCP/IP- Stack zu werden, auf der beliebige Anwendungen liegen. Dort sehe ich durchaus interessante Vor- und Nachteile... ;)
Viele Grüße, Kristian
Am Freitag, den 15.11.2019, 08:32 +0100 schrieb Stefan Engelhardt:
Guten Morgen, klingt interesannt. Leider kenne ich die Funktionsweise von SMTP/IMAP nicht um das tatsächlich vergleichen zu können. Würde mich aber freuen wenn diese Diskussion hier nicht im Sand verläuft und ein paar nützliche Informationen bekannt werden würden.
[...]
Am Do., 14. Nov. 2019 um 12:37 Uhr schrieb Thomas Güttler < guettliml@thomas-guettler.de>:
dass so etwas fehlt, geht mir schon lange durch den Kopf. Mal sehen wann es wirklich nutzbar ist:
https://jmap.io/
Am 15.11.19 um 11:07 schrieb Kristian Rink:
Guten Morgen;
alle: Danke für den Link. Hatte ich noch nicht auf dem Schirm. Finde ich... interessant. Auch wenn spontan die erste Frage natürlich ist: Ist HTTP+JSON das Werkzeug der Wahl für *jedes* Problem? Momentan scheint mir das zu einer zusätzlichen Layer auf dem bekannten TCP/IP- Stack zu werden, auf der beliebige Anwendungen liegen. Dort sehe ich durchaus interessante Vor- und Nachteile... ;)
Ich denke PWAs werden die Zukunft sein: Progressive Web Apps. Also Apps die funktionieren ohne dass man sie installieren muss. Und JavaScript im Browser kann eben nicht aus seinem Käfig ausbrechen und über TCP mit IMAP reden. Es gibt JS Bibliotheken die IMAP können, aber die laufen nur unter zB Node.js serverseitig.
Ich finde es mächtig spannend.
Für alles "offizielle" ist weiterhin Mail das Mittel der Wahl, und das wird sich so schnell nicht ändern. Weil sich eben noch keinen gemeinsamer Nenner gefunden hat. So ist mit JMAP vielleicht eine schrittweise Verbesserung des Zustands möglich.
Gruß, Thomas
Hallo;
Am Freitag, den 15.11.2019, 13:54 +0100 schrieb Thomas Güttler:
Ich denke PWAs werden die Zukunft sein: Progressive Web Apps. Also Apps die funktionieren ohne dass man sie installieren muss. Und JavaScript im Browser kann eben nicht aus seinem Käfig ausbrechen und über TCP mit IMAP reden. Es gibt JS Bibliotheken die IMAP können, aber die laufen nur unter zB Node.js serverseitig.
Ja, ich kenne und verstehe den Ansatz. Bin zweigeteilt. Scheint mir auf der einen Seite eine gute Möglichkeit, "portable" Anwendungen einfach über Plattformen zu verteilen, ohne allzu viel verschiedene native Technologien in der Hand zu haben (und damit das zu liefern, was Java immer versprochen, aber nie richtig geschafft hat).
Andererseits ist mir der gesamte Tool-Stapel dafür, insbesondere und ganz vorn eben node.js. npm und Freunde, in vielen Aspekten zutiefst suspekt. Insofern fehlt mir hier Euphorie für die Idee, und der Umstand, damit für *jeden* Use Case auf HTTP als Transport festgelegt zu sein, macht die Sache auch nicht zwingend besser... ;)
Viele Grüße, Kristian
lug-dd@mailman.schlittermann.de
-
Kristian Rink -
Stefan Engelhardt -
Thomas Güttler -
Thomas Köhler -
Thomas Schmidt