Any word on M3? (internal mail client)

Ayespy

@Codehunter said in Any word on M3? (internal mail client):

The only logical explanation for the delays is that it is not being worked on with high priority.

This would be incorrect.

Not all "email clients" are created equal. It's relatively simple to fetch and display mail. But a full-featured client must do much, much more. M2 was such a full-featured client, and the original goal was to at least match that level of performance.

What's correct is that few developers know how to write a full-featured email client, and even fewer are conversant with email clients, databases and database operations. This led to Vivaldi starting with a very small mail team, only two developers, and only five people (if I'm remembering correctly) on the team at present. Then, too, it had to be completely integrated into Vivaldi, using the same rendering and interface processes as the browser. While it has been being written, GMail, which uses a completely non-standard structure to begin with, has been changing how its login, folder structures and folder subscriptions are handled, making it necessary to re-write parts of the client multiple times. To make matters worse, a full email client is actually much more complex than a browser. So even though it has been a top priority from day 1, it has been taking longer than expected to get done. It is in a very workable and usable state right now, and I use it as my primary mail client daily, but it is not, for certain nagging reasons, ready for public consumption yet.

Codehunter

Youre right, a mail client has to deal with many things. But more complex than a browser? No, really. Handling network connections and SSL/TLS - already in Vivaldi. A high performance local storage and fulltext index - we have a lot of modern DBMS available which can do it. The UI is the main challenge. It must be simple, powerful, seamlessly integrated into Vivaldi and can't forked from other projects.

Some unexpected gmail changes? Maybe, but Google is not the only mail provider, not the greatest, not the most important and not the most privacy protected. IMHO not important enough to let it be a showstopper for M3. Jon itself has sayed that Google becomes evil more and more and now they, of all providers, are the reason for the delays? I cant remember that the Vivaldi team has asked us which mail provider we prefer. In any case, this is no good reason for 5 years of delay.

And there was a decision, wrong in my eyes, to give priority to IMAP instead of POP3. Both have advantages and disadvantages. But IMAP is much more complex to make and keep remote and local storages in sync. I can imagine that IMAP can overwhelm a small team. Maybe the gmail issues was a consequence of the IMAP decision.

Ayespy

@Codehunter Gmail, however, is widely used, forcing M3 to be compatible with it. To not work with GMail would be one of several possible deal-breakers.

And so's you know, IMAP and POP3 have equal stature in M3 at present. But as IMAP is the primary means of dealing with email internationally, now, a mail client without it would be dead on arrival.

While you're designing your mail client, consider: How will you deal with labels, flags and filters? How will you enable these, and how will they interact with server-side data? What about mail lists? Will you recognize them, show/hide them, make it possible to manipulate them? How will you deal with duplicate emails? Will you actually have multiple folders to put emails in, or only multiple views through which to interact with only a single, unique email in each case? Will you have discrete permanent local copies of mails, or rely on server-side operations to tell your client whether to keep or lose the email? How about compositing? What options will you offer, and how will you implement them? If for some reason, there is a dodgy server connection and it is hard to complete data operations or stay logged on, how will your mail client handle that? Which settings in the client will be persistent, and which ephemeral? Will you subscribe to every IMAP folder at the server side, or just some of them and, if the different folders contain different copies of the same email, how will you deal with that? Will you integrate a news reader, and how, and what capabilities/features will it have? What about contacts handling? What will be the rules for contact creation, what data fields will be accommodated, and how will these be recognized at a remote server? Will a calendar be integrated with mail, or vice-versa, and how? When you are choosing which mail list views to offer, what will be the options in each list? Will you make it possible to see read emails, spam, or trash in lists not specifically devoted to these emails? If so, how will you implement that? How will you toggle those views? Will there be a global inbox or separate inboxes, or both? How will you implement that? How complex will filters be able to be, and how will you implement them? How will you implement search? How will you make all of the above operations fast, smooth and efficient, getting the most done in the shortest time, with the least resources? Where, how, and in what format will you store email bodies? And EVERYTHING you are doing locally, how will it be handled over IMAP and over POP3? How will you ensure database consistency? Every email client has a problem with broken databases. How will you ensure compatibility with every mail server any user wants to access?

These are fewer than half of the questions you will want to answer while designing and building your email client, and only one of them even addresses one of the hundreds of problems with databases inherent in making a client capable of reliably storing, accessing and manipulating over a half million emails in the same profile, without data loss.

I've been watching this thing get built at close quarters for about four years now, and it has completely disabused me of a lifetime's worth of assumptions about emails and email clients. I thought it was an outbuilding, to be connected with a breezeway. It is its own, entire, edifice - and with more moving parts than the browser.

Codehunter

@Ayespy I agree with you in most points. But not on two points:

To wait until a software is perfectly developed. Perfection is unreachable and the try will result in endless delays. I think this is what we have with M3.
The equality of POP3 and IMAP. They have a fundamental difference: POP3 is designed for local mail storage, IMAP vice versa for server-side storage and management. To try to deal both in the same way in a client with local storage will result in a more complex code - and finally in development delay.

About gmail: You said, their implementation is non-standard and changed some times. Do you remember, what Google once said about MSIE? In short: "Non-standard is evil. To force others to be compatible with it is evil." Now they become evil themselves. Hold in a moment and think about... There are thousands of coders on Google. If they need 1000 working-hours to change the interface, its done in e.g. three days. When Vivaldi try to follow it with M3 and has five fulltime devs (for example 40 working hours per dev and week), they will need five weeks to reach the goal. But Vivaldis devs does not only work on M3. So they need five months or so. Its like coyote and the roadrunner: Will never success, even not with a rocket on its back.

I think this is a strategy to hold down small competitors. And when I read what you wrote, successful. Lets play a mind game: Suppose you were to say "We can release M3 tomorrow if we drop gmail support or we can release M3 in a far, far future with gmail support." What do you think which of both options is choosen by the majority of the Vivaldi users? Google is not infallible either. Remember whats happened with G+. They said pompously "Wer'e much bigger, expierenced and better anyway than FB. We made G+ and it will be success automatically." They failed. I think, gmail is not the ultimate wisdom.

P.S.: Good to hear that POP3 is in M3 now. This was new to me.

Edit: Before I will forget: I think, your'e right about the complexity of mail client code but not about the comparsion to a browser engine. Can you imagine, how many different "bullshit" HTML code is present in the WWW? In comparsion to the clarity of POP3 and IMAP, it's sheer horror. I'm fascinated every day how fast, stable and reliable is modern browser engines.

Blackbird

@Codehunter said in Any word on M3? (internal mail client):

@Ayespy I agree with you in most points. But not on two points:

To wait until a software is perfectly developed. Perfection is unreachable and the try will result in endless delays. I think this is what we have with M3. ...

There is an age-old debate about when any design is truly developed well enough for final release or production. Time-worn expressions like: "On any job, there comes a time to shoot the engineers and get on with production", "it's good enough for government work", or "to keep on designing is to gild the lily" are countered with "how could they have made it without getting 'xxx" to work right", "all that work and the product still lacks 'zzz'", or "what could they have been thinking to ship something like this".

At the end of the day, determining the point when a product is truly ready for release must remain with the maker alone. Only he can accurately balance his resource costs and his intimate knowledge of the product design itself with his assessment of what the marketplace will require of the end item (and how that will reflect on the maker's reputation). Once the product is released, the marketplace customers will have the opportunity to 'vote' on the wisdom of the maker's release decisions.

The real question for those of us on the 'outside' is to what extent one trusts Vivaldi's makers to make a wise decision about the release of M3. Given the importance of e-mail in my world, I want the end product to be flexible and as reliable as humanly possible across the broadest range of situations encountered in daily usage. In that regard, I respect Vivaldi's cautious approach to this entire issue, and based on their demonstrated past design experience over many years, I trust that their end product (just as with their browser) will be well worth the wait. In the meantime, I continue 'getting by' with what I've used since the old Opera M2 days.

Ayespy

@Codehunter said in Any word on M3? (internal mail client):

I think, your'e right about the complexity of mail client code but not about the comparsion to a browser engine.

In this case, I make a distinction between the rendering engine and what the Vivaldi team are producing, which is the UX side. There's five times as much code in the renderer and V8 as in everything Vivaldi is writing, combined.

Codehunter

@Ayespy said in Any word on M3? (internal mail client):

@Codehunter said in Any word on M3? (internal mail client):

I think, your'e right about the complexity of mail client code but not about the comparsion to a browser engine.

In this case, I make a distinction between the rendering engine and what the Vivaldi team are producing, which is the UX side. There's five times as much code in the renderer and V8 than in everything Vivaldi is writing, combined.

Then I agree with you. My point of view is from the time in which Jon has led Opera. In that time his team has written a renderer, JS runtime, a browser and a mail client - successful. Does anyone know how much devs was involved at that time?

Ayespy

@Codehunter It started with 2 (Jon and Geir Iversoy, 1995), and wound up with over 200 (2013).

Codehunter

@Ayespy said in Any word on M3? (internal mail client):

@Codehunter It started with 2 (Jon and Geir Iversoy, 1995), and wound up with over 200 (2013).

Ok, its a little difference to now But M2 was introduced when? As wikipedia says it was introduced with Opera 2 in 1996. I was Opera user since v5 in 2000 (at that time the browser had a ad panel in the upper right corner). And the cause why I'm migrated from Netscape was... M2. The oldest mail in my inbox is from 01.01.2001. And as I remember, M2 was very good at that time. So I'm sure that Jon knows how to write a good mail client. What I want to say is: Do not overdo it with perfection

Ayespy

@Codehunter Perfection is not sought. Reliability is.

Codehunter

@Ayespy said in Any word on M3? (internal mail client):

@Codehunter Perfection is not sought. Reliability is.

Fine! But I did not believe that compatibility to gmail is a factor in reliability.

Blackbird

@Codehunter said in Any word on M3? (internal mail client):

... But I did not believe that compatibility to gmail is a factor in reliability.

As of 1 July 2020, the 38% of all e-mail users who currently employ gmail clients would probably disagree (https://emailclientmarketshare.com/). Vivaldi's not reliably providing gmail access in M3 would kill off any incentive for over 1/3 of the existing client marketplace to migrate to M3... just for openers.

Ayespy

@Codehunter Turns out that in the real world, it is. It's not the only factor, but one which can't be ignored.

That's partly my fault. As a tester, I have been a leading reporter of such compatibility issues (though not the only one), given that as far as I can tell, none of the current developers even uses a GMail account, while I use three of them, that contain both native and imported (from Eudora, Outlook Express, Thunderbird, Netscape Communicator and M2) mails going back to 2001. Hence, I'm able to find problems no one else even runs into.

Codehunter

@Blackbird said in Any word on M3? (internal mail client):

@Codehunter said in Any word on M3? (internal mail client):

... But I did not believe that compatibility to gmail is a factor in reliability.

As of 1 July 2020, the 38% of all e-mail users who currently employ gmail clients would probably disagree (https://emailclientmarketshare.com/). Vivaldi's not reliably providing gmail access in M3 would kill off any incentive for over 1/3 of the existing client marketplace to migrate to M3... just for openers.

38% and not a single one is a M3 user. And in my opinion such market share analyzers are very imprecise. When they analyze all the mail traffic (how ever they do that) the main statement is that gmail has the most spam ^^

Ok, lets end up the gmail point. My suggestion is: Ask the community how important gmail is. Or any other aspect of M3 delay.

luetage

@Codehunter This isn’t a democracy and you can’t force an official release this way. What should have happened years ago on the other hand is a release as an experiment. I probably said this 12 times already in this thread, but the release can’t be perfect anyway without very broad testing. Don’t know why this hasn’t happened. And I can understand anyone who will be dissatisfied with an official stable release ridden by bugs after waiting for 5 years on it. You really can’t win after this amount of time has passed. Especially considering that anyone but a couple dozen hardcore users have moved off M2 to greener pastures a long time ago.

Pesala

The official policy of Vivaldi should be to wean users off of Google products, including Gmail.

If users still want to use Gmail, or have to due to company policy, then they can continue using it even if it is not supported by M3.

I still use a Gmail account for feedback on my website, because it is mostly spam anyhow, and I use it as a registration address because I don't care much about it.

My Opera 12.18 client fetches email from Gmail, but I can turn that off it becomes too annoying, and revert to using the Webmail account for my Gmail account, which is what I already do.

jumpsq

@luetage said:

greener pastures

Ain't nothin' fresher and tastier than a well aged M2.

burnout426

@Ayespy said in Any word on M3? (internal mail client):

GMail, which uses a completely non-standard structure to begin with, has been changing how its login, folder structures and folder subscriptions are handled, making it necessary to re-write parts of the client multiple times.

Do you have details on what Gmail has changed that caused breakage in M3?

jumpsq

@burnout426 I guess that partially this is about OAuth 2.0. And maybe 2FA?

burnout426

@jumpsq Hmm, don't know. Can M3 can still log in to Gmail via normal password (base64 plain text) authentication over TLS? That still works in Thunderbird for Gmail IMAP/SMTP at least.