Open letter to Jon concerning M3
-
@morg42 said in Open letter to Jon concerning M3:
Very well written, thanks for your letter!
I agree that a mail client like M2 (or even better) is missing and I see how many people are eagerly awaiting its arrival.
Maybe you can enlighten me on a topic which I just seem unable to comprehend up to now: why do many apparently need M3 as a Vivaldi integrated feature? Why not release M3 as a separate client which can be used independently of or completely without Vivaldi?
More generic: what benefit do you see for yourself if many features are packed into one application? Are there integration benefits to combining mail and www? Or is it just easier not to switch apps?This is a topic that is very often asked in connection with Opera and M2. After all, Opera simply removed the M2 mail client from the Opera browser and released it as a separate program. To put it simply, the difference is nothing more than the mouse path you have to move back and forth to switch between the two parts of the program. Whether the switch is located in a browser toolbar or the taskbar of the operating system, this is actually just a question of the user's habit.
As a developer, I can also say that it doesn't make a lot of difference from a technical point of view whether you pack both parts into one application or into two separate ones. There are even techniques that allow you to connect separate programs with each other in such a way that they look like one - similar to plugins in Firefox or Chrome. Only the plugins do not work without the browser.
Das ist ein Thema, dass sehr oft im Zusammenhang mit Opera und M2 gefragt wird. Schließlich hat die Firma Opera den Mailclient M2 einfach aus dem Browser Opera ausgebaut und als separates Programm veröffentlicht. Der Unterschied ist, vereinfacht gesagt, nichts weiter als der Mauspfad, den man zurück legen muss um zwischen den beiden Programmteilen umzuschalten. Ob der Umschalter nun in einer Toolbar des Browsers liegt oder der Taskbar des Betriebssystems, das ist eigentlich nur eine Frage der Gewohnheit des Anwenders.
Als Entwickler kann ich auch sagen, es macht technisch gesehen nicht viel Unterschied, ob man beide Teile nun in eine Anwendung packt oder in zwei getrennte. Es gibt sogar Techniken, mittels derer man separate Programme so mit einander verbinden kann dass sie wie eines aussehen - vergleichbar mit Plugins in Firefox oder Chrome. Nur dass hier die Plugins nicht ohne den Browser funktionieren.
-
@morg42 said :
More generic: what benefit do you see for yourself if many features are packed into one application? Are there integration benefits to combining mail and www? Or is it just easier not to switch apps?
I think, that many people used the mail panel in O12 times, so you had always a quick overview.
But if I remember correctly, someone has explained it like this (maybe Jon himself?):
you need a renderer to display the html mails correctly. And if you have a mailprogram with a render engine, then it's easy to use the render engine also for browsing websites, so you also reduce the hardware resources. -
@codehunter Thanks for this detailed message and for your support to Opera and now Vivaldi.
I can tell you that we are very eager to get M3 out. I have been using it myself, as a replacement for M2, for more than a year now. During that time it has improved a lot. I would not dream of going back to M2. That being said, there are still things to do. Although a lot of the heavy lifting is done, there are still issues to resolve with regards to stability and memory usage in particular and there are still unfinished features and even missing features. Sadly that includes POP3 at this time, but I do hope we will get to it soon.
We have used some third party libraries this time as well, but there is still a lot of work to get this right. We have enough resources on this task, although one could always use a bit more. That being said, we do not need external funding. If you want to support us, please share Vivaldi with your friends. That is the best way to support us, as the more users we get, the better.
I would hope we have some really good news in the months ahead. M3 is looking great and looking better each day. Just give us a little more time and I believe it will have been worth the wait.
Best,
Jon. -
@codehunter said in Open letter to Jon concerning M3:
To put it simply, the difference is nothing more than the mouse path you have to move back and forth to switch between the two parts of the program. Whether the switch is located in a browser toolbar or the taskbar of the operating system, this is actually just a question of the user's habit.
This is what I thought.
As a developer, I can also say that it doesn't make a lot of difference from a technical point of view whether you pack both parts into one application or into two separate ones. There are even techniques that allow you to connect separate programs with each other in such a way that they look like one - similar to plugins in Firefox or Chrome. Only the plugins do not work without the browser.
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.
@derday said in Open letter to Jon concerning M3:
I think, that many people used the mail panel in O12 times, so you had always a quick overview.
I have a system-wide mail panel, others may not. Ok...
you need a renderer to display the html mails correctly. And if you have a mailprogram with a render engine, then it's easy to use the render engine also for browsing websites, so you also reduce the hardware resources.
That is a valid point I had not thought of before. My mail program is console only, so for me HTML mails are a nuisance anyway. The backup (Airmail, also on mobile, see above) does display. It might be worth using the V renderer - but then I'd like to have some control over what elements might be loaded / activated (external resources, scripts, ...)
Thanks for your feedback!
-
I would be happy with IMAP only!
-
I would be unhappy with IMAP only! In fact, i would not use any email schema that precluded POP3.
-
@steffie Well, to be fair, however it is released initially, it will have POP3 ultimately.
-
@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"
-
@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.
-
@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...)
-
@ayespy said in Open letter to Jon concerning M3:
I have 2 offices 630 miles from each other
Makes one wistful for schizophrenia, eh?
-
@ayespy said in Open letter to Jon concerning M3:
... And I personally must have POP3 for permanent business records. ...
This!!
-
@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.
-
@ayespy Which email provider?
-
-
@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 -
@luetage I'll pass on the info.
-
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.
-
@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.
-
@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...