Open letter to Jon concerning M3

[Steffie]

@ayespy I know [i listened to the podcast yesterday & was gratified with Jon's assurance]. My post here was merely aimed as a 100% counterpoint to any instance where i read other users opine that IMAP-only would be ok... it would not. My logic is that if POP3 supporters stay quiet & only IMAPers post [implausible i know, but i'm all about principle] then over time a false perception would arise that the V community only cared about IMAP.

You know, it's my version of the classic aphorism "When good women do nothing, IMAP arises" or the alternative "All that is necessary for the triumph of IMAP is that good women do nothing"

[Ayespy]

@steffie Well, one of our strongest and most prolific Sopranos and moderators lives in Germany, and their local email provider has only POP3, no IMAP. If there's no POP3, I fear there will be an internal rebellion.

[Ayespy]

@steffie And I personally must have POP3 for permanent business records. For the time being, I turn on a POP3 client periodically just to download and permanently store all email incrementally. I run a MAPI client routinely, so as to synchronize emails on my various and diverse devices in multiple locations (because, for instance, I have 2 offices 630 miles from each other...)

[Steffie]

@ayespy said in Open letter to Jon concerning M3:

I have 2 offices 630 miles from each other

Makes one wistful for schizophrenia, eh?

[Blackbird]

@ayespy said in Open letter to Jon concerning M3:

... And I personally must have POP3 for permanent business records. ...

This!!

[Steffie]

@ayespy said in Open letter to Jon concerning M3:

must have POP3 for permanent business records

See? That's it, that's what i simply do not get about IMAPers. IMO it's simply madness to presume that one's critical personal &/or business records are safe when kept on someone else's remote servers rather than in the individual user's own local system. One does not need to be a tinhatter to feel this way; there are various cases when 3rd party email providers either simply shut up shop without notice, were hacked, or were OoS for extended periods for tech reasons. To place one's faith in the permanent availability of others' facilities, & risk one's own data on that flawed premise, is loopy IMO.

[luetage]

@ayespy Which email provider?

[Ayespy]

@luetage GMX.de as best I recall.

[luetage]

@ayespy That's what I thought. It's probably the biggest email provider in german speaking countries. But it's a mistake to believe IMAP isn't working -- I'm using it on my gmx address for over 10 years, on a free account (no pro version needed).

Give them this link.
https://hilfe.gmx.net/pop-imap/imap/imap-serverdaten.html

[Ayespy]

@luetage I'll pass on the info.

[saudiqbal]

I have been using Gmail since it came out, therefore imap is enough for me. I read and delete my emails, so no need for any pop3 for me.

[Codehunter]

@morg42 said in Open letter to Jon concerning M3:

I see clear advantages to developing separate apps: you can have independent release cycles, maybe even different dev teams, and although often overlooked, smaller downloads for the individual programs.

This point is actually raised every time the issue is raised. Those who know a little bit about software development know that this is wrong.

Most applications are modular and use dynamic libraries (. dll under Windows, I think they are called. so under Linux). The function parts that both programs have to share, for example the renderer for HTML mails and image attachments. However, there are also parts of code that cannot be stored in libraries. These are compiled into the main program. Exactly these parts lead to the fact that both programs would be bigger together than if one integrated the function part E-Mail directly into the browser program. However, the difference is likely to be in the single-digit megabyte range. This is unlikely to be a problem at the present time, even with below-average Internet connections.

I also see advantages in the development of a monolithic application. Especially the common work of the developers on browsers and mailers can lead to a better security of the mailer. You have seen for a long time what happens when independent teams have worked on IE and Outlook. The mailer was full of security flaws until the development was structured differently.

Maybe we should look at e-mail differently now than before. Historically, POP3/SMTP and HTTP have come from different directions. We therefore tend to view them separately. However, they have continued to grow together. Since webmail interfaces have existed in the browser (the prime example here is OWL - Outlook Web Access), the boundaries between the two services have finally become blurred. Actually, it is no longer the transmission protocol that matters, but how we communicate today. One could also say that every webchat is a further development of AIM and ICQ. Everything has been moved from a separate program to the browser.

From a technical point of view, the only difficulty is to integrate the shortcomings of the stone age protocols SMTP, POP3 and IMAP into a modern program and implement local data management.

---

Dieser Punkt wird eigentlich jedes Mal angeführt, wenn das Thema zur Sprache kommt. Wer sich ein wenig mit Softwareentwicklung auskennt, der weiß dass das falsch ist.

Die meisten Anwendungen sind modular aufgebaut und nutzen dynamische Bibliotheken (.dll unter Windows, unter Linux glaube ich heißen sie .so). Die Funktionsteile die beide Programme gemeinsam nutzen müssen, beispielsweise eben den Renderer für HTML-Mails und Bildanhänge. Es gibt jedoch auch Codebestandteile, die sich nicht in Bibliotheken auslagern lassen. Diese werden fest in das Hauptprogramm einkompiliert. Genau diese Teile führen dann dazu, dass beide Programme zusammen größer wären als wenn man den Funktionsteil E-Mail direkt in das Browserprogramm integrieren würde. Der Unterschied dürfte sich aber im einstelligen Megabyte-Bereich bewegen. Das dürfte in der heutigen Zeit selbst mit unterdurchschnittlichen Internetanschlüssen kaum ein Problem sein.

Ich sehe dagegen auch Vorteile in der Entwicklung einer monolithischen Anwendung. Gerade die gemeinsame Arbeit der Entwickler an Browser und Mailer kann eine bessere Sicherheit des Mailers bewirken. Man hat ja lange Zeit gesehen, was passiert wenn unabhängige Teams an IE und Outlook gearbeitet haben. Der Mailer war mit vielen Sicherheitslücken behaftet, bis man die Entwicklung anders strukturiert hat.

Möglicherweise sollten wir E-Mail inzwischen auch anders betrachten als früher. Historisch sind POP3/SMTP und HTTP aus verschiedenen Richtungen gekommen. Wir neigen dazu, sie deswegen getrennt zu betrachten. Jedoch sind sie immer weiter zusammen gewachsen. Spätestens seit es Webmail-Interfaces im Browser gibt (das Paradebeispiel ist hier OWL - Outlook Web Access), sind die Grenzen zwischen beiden Diensten doch endgültig verschwommen. Eigentlich kommt es doch gar nicht mehr auf das Übertragungsprotokoll an sondern wie wir heute kommunizieren. Man könnte doch auch sagen, jeder Webchat ist eine Weiterentwicklung von AIM und ICQ. Hier wurde doch auch alles von einem separaten Programm in den Browser verlegt.

Die einzige Schwierigkeit aus technischer Sicht besteht doch darin, die Unzulänglichkeiten der steinalten Protokolle SMTP, POP3 und IMAP in ein modernes Programm zu integrieren und eine lokale Datenhaltung zu implementieren.

[Morg42]

@codehunter said in Open letter to Jon concerning M3:

Exactly these parts lead to the fact that both programs would be bigger together than if one integrated the function part E-Mail directly into the browser program.

I only said that the single-program downloads were smaller (than an integrated one), not that both together were smaller. Combined with release cycles, this might save some bandwidth.

However, the difference is likely to be in the single-digit megabyte range. This is unlikely to be a problem at the present time, even with below-average Internet connections.

Seeing how (mobile) internet traffic is being weighed in gold e.g. in Germany (compare volume rates and offered data packages to Austria or Scandinavia) and also that mobile bandwidth is only a shared resource, I think there is not enough consideration towards keeping traffic volume down. (Not even to think about video streaming or ad volume..)

This is not so much a practical problem as a general question of principle, as you may have noticed...

I also see advantages in the development of a monolithic application. Especially the common work of the developers on browsers and mailers can lead to a better security of the mailer.

Which just goes to say that the security level of the shared libraries is inherited by all applications using it. Thay may or may not be an advantage...

You have seen for a long time what happens when independent teams have worked on IE and Outlook. The mailer was full of security flaws until the development was structured differently.

Choosing Outlook and IE of all things as an example for security seems.. bold. I hold this to be the prime example of why not to integrate browser and mail technologies. While a browser might be seen as a multifunctional JS-based application host (and still has security issues caused by JS program code), I can't see why this should even be possible in Mail. I'd envision a really tiny HTML renderer for mails (if any), which doesn't even know what to do with JS...

Maybe we should look at e-mail differently now than before. Historically, POP3/SMTP and HTTP have come from different directions.

Funnily, this is not true. Historically, both mail and www were meant for pure information exchange, as gopher before. No one needed fancy font faces or coloured text in mails. It was about content... once.

We therefore tend to view them separately.

And seeing how security-minded many people are towards websites today (luckily), and how naive (security-wise) many people are towards mails today, as well we should view them separately.

Can you tell me why phishing - even in worst form with bad grammar and orthography - apparently works so well that still someone invests money to send the mails?

No, mail should absolutely not be seen in unison with the web.

Sure, one fundamental problem of mail is the "transport organisation", proving who sent a mail still is not possible without getting deeply involved. But as long as this is not resolved, I think it should be a task of the mail client to protect people from harm. And showing fancy login pages and barely facsimile links to known sites should not be encouraged.

However, they have continued to grow together. Since webmail interfaces have existed in the browser, the boundaries between the two services have finally become blurred.

Sorry, but I don't agree.

The browser is - per webmail - increasingly used as a mail client, yes, I guess you are right there (even if I don't see the upside except for universal accessibility).
But a webmail client will never be able to perform as well, as fast, as feature-rich as a dedicated mail client. (The fact that in most (?) cases webmail binds you to the specific mail provider is still another thing.)
Seeing mail as just another application of www leads to exactly the problems we have. Most integration between mail and www seems to be opening links and not having to switch applications for whatever reasons.

One could also say that every webchat is a further development of AIM and ICQ.

Did you ever use IRC?

Everything has been moved from a separate program to the browser.

Hm. If I examine my systems, my browser is only used for browsing (including forums). I have separate mail, chat (irc, whatsapp), terminal, text edit, maps, news (rss), calendar, contacts, banking and whatever apps. I even use a plugin to integrate text editor and web browser, so I can use the extended functionality and comfort of my text browser over a browser-provided text field editor to write this message...

But this is exactly the point. As long as for you everything converges in the browser and you don't want (and don't see) my perceived advantages and added value of separate apps, we will not get on the same side of the argument. I am aware that my conception of using technology might be different from that of many other people.

From a technical point of view, the only difficulty is to integrate the shortcomings of the stone age protocols SMTP, POP3 and IMAP into a modern program and implement local data management.

If you solely use IMAP, a browser webmail client might suffice. As soon as you want local storage, a dedicated mail client is essential (if the mail client is integrated into the browser is not relevant to this point). Again, you have other ways of organising storage, indexing and searching with a native application than with a webmail interface using some kind of HTML5 local storage for mail archives. (my mail archive is ~5 gig from 2000 onward plus some MB index files, maildir format).

But this might get a bit off-course for the topic...

Personally, I'd be happy to see a separate M3 client, but I will not abandon V if it only comes integrated...

[Ayespy]

@morg42 It will come integrated, as I am using it now, and much to my advantage.

My optimal workflow is email (from which I obtain my jobs to be accomplished), bookmark to open the relevant initial page, bookmarks, tabs and webpage interface to move to additional sites, transfer of data to a text document, draft report, edit and email the document, go to the next assignment received in email. Frequently during research, I will move seamlessly between email, web pages, back to email, new tab, back to last tab, reference email again, etc. When email, web, tabs and bookmarks are all available at the same time in the same UI, my work is substantially faster than if I have to shift back and forth between apps.

I developed this workflow while using Opera 12 et prior, which had integrated email and the ability to integrate my email, web, bookmarks, tabs in vertical columns in the same interface in a wide gamut monitor. It is devilishly efficient, and my prime reason for wishing to have integrated email. Using email within Vivaldi returns me to the comfort of my old habits that I developed over more than a decade with Opera.

Further, email adds MUCH less to the size of Vivaldi than downloading or updating a discrete email client, adds efficiencies in resource usage on the platform, and best yet, adds zero to overhead if you don't activate it and set up accounts. Even with it activated, Vivaldi with email consumes much less overhead than Vivaldi plus separate email client. Plus, the presence and use of integrated email seems, to me at least, to impact browser performance not one iota. So to me, integrated email just makes sense. When Opera dropped it and it looked like I might never have it again, I really despaired.

But that's just me, one user.

[Ayespy]

@morg42 And, btw, the download with email is 1.56 Mb larger than the download without email.

[Morg42]

@ayespy said in Open letter to Jon concerning M3:

But that's just me, one user.

I accept everyone who has different views, workflows or peculiarities. I am only a single user, too.

[Pesala]

Why open another application for email? I spend most of the day online. Even if I am using another application to write a book or publish a web site, I will have my browser open for looking things up. Meanwhile, I have Opera running too (on my secondary monitor) so I can see at once if some email comes in.

I stop whatever I am doing, saving my work, before reading the email and dealing with it at once. If I am unable to reply to it for some reason, I tag it, then get on with whatever I was doing before.

After many years of using Opera M2, I still have fewer than 100 emails saved, but I would not want them to be on a server where I cannot access them if my Internet connection is down, etc.

[Morg42]

@pesala said in Open letter to Jon concerning M3:

Why open another application for email?

Yeah. Exactly the kind of argument I'd been waiting for...

I will have my browser open for looking things up. Meanwhile, I have Opera running too (on my secondary monitor) so I can see at once if some email comes in.

So if instead of Opera it was another program for mail, this didn't make a difference? (while it's not integrated in Vivaldi)

I would not want them to be on a server where I cannot access them if my Internet connection is down, etc.

Which is an argument against web mail, but not against dedicated email clients, no matter of which make...

[netwolf]

Slightly off topic, but what's your problem with IMAP?

The secret service part is a joke I guess (nobody seriously believes a SS can't access server-side POP3 traces or MITM the mail fetch), and you can very easily keep a local copy of your mails with IMAP too if you want to.

A few years ago I switched all my account to IMAP and now have them perfectly accessible and synced(!) on all my devices. Nevertheless my Thunderbird is configured to keep local copies of all mails, so even offline I have perfect access to them.

WRT internal/external tool: IMHO only an integrated solution makes sense, as integration is the most important advantage over the dozens of very good email tools available, which are years of development and experience ahead.
THE advantage (at least for me) of M2 is/was that mail (and feeds) is just another tab, not a separate standalone application outside the browser.

[Pesala]

@morg42 said in Open letter to Jon concerning M3:

Exactly the kind of argument I'd been waiting for...

You are looking for arguments, contrary to your alleged acceptance that people have different workflows.

This thread is about the built-in email client, but you don't want it. That is fine by me, but I find that it being built-in improves my workflow as my screenshot shows.

IMAP would be fine if I can store local copies of my email, and then delete it from the server.