Any word on M3? (internal mail client)
-
Here's the official announcement thus far and as luetage stated, there's seems to be very little about mail itself, and more about trying to stuff 10 pounds of features into a five pound bag. At first blush, it looks like a complete mess. But who knows, perhaps it's more eloquent in practice? Anyway, in taking the internet's temperature about what's on the horizon, it's seems that a whole lot of people are practically begging for an alternative right about now.
-
If Vivaldi can implement Peer-to-Peer file-sharing like Opera Unite, users might have a way to collaborate without sharing their data with Google, or anyone else that do not wish to share with. Zoom has also proved to be at risk of being hacked.
-
@jdvernet said in Any word on M3? (internal mail client):
... as luetage stated, there's seems to be very little about mail itself, and more about trying to stuff 10 pounds of features into a five pound bag. At first blush, it looks like a complete mess. But who knows, perhaps it's more eloquent in practice? ...
Actually, it's a five-pound bag in which everything in it passes under the nose (and through the hands) of Google, whose entire 'reason for being' is to make money off the marketing of user data in one form or another. Personally, it's not a path I'd ever choose to take...
-
@purgatori They use it because it's free, the storage is relatively huge, and Google provided it blanket promotion, just like they did Chrome. Hundreds of millions became addicted to GMail back when they still believed in "Don't be evil."
-
It is a serious mistake to become addicted to any email address.
-
@Pesala And yet, when you have hundreds of customers or business contacts who contact you that way, you do. I even had a customer who kept changing email addresses every few months. I never knew who his emails were coming from, or where to send his results. After a while, I had to resist the impulse to do him physical harm.
-
@purgatori Because... baa, baa, baaaaaaaaaaaaaaaaaaa.
-
@Ayespy We are not talking about changing email addresses every month. Maybe every ten years, or whenever it becomes necessary. Then you email your list of contacts with the updated address, and change your email on your social media accounts.
Businesses sometimes have to move their physical address, and reprint letterheads, business cards, etc. Email is no different. Do not let anyone hold you to ransom.
-
@Ayespy said in Any word on M3? (internal mail client):
Every time Google changes something on the GMail backend, it breaks M3 (again).
A well known Ibm product does the same, breaking many softwares during its upgrades,
the differences are, one do it intentionally. -
I miss Opera Presto (Now Vivaldi! ) so much. I started using it since version 7. It quickly became my browser of choice. What I loved about it was its comprehensive features, which were well integrated. M2 and Feeds were killer features, in my opinion.
I am very happy with the way Vivaldi is progressing. While it is not my default choice (Firefox) I am planning to switch soon once I import all my links manually (Yeah! I am like that, I don't like importers).
I am eagerly awaiting M3, Calendar and Feeds. I can then finally discard Thunderbird, Lightning and Firefox. While I desire certain improvements to Vivaldi's UI, overall I am very pleased. The developers are so responsive, just like the in the days of Presto.
Thank you! @jon and your team for a great product.
-
There are many "chrominoide" browsers which differs in UI but the entire features are the same on each. That's more a matter of taste right now. Some people says "Wah Vivaldi is a fat browser". But I say: Let it fat when it is unique. O12 was unique because of M2 and Presto. But what makes Vivaldi unique? Currently it is just another fork of Chromium with a pretty and useful UI, sure. But unique? Not really. No M3, no own renderer.
I'm aware of the impossibility to write a new engine from scratch for a small company like Vivaldi. But M3 should be feasible for a little team. The only logical explanation for the delays is that it is not being worked on with high priority. So the most important question is: Why should the Vivaldi devs work on M3 with high prio? In my opinion the answer is: The Vivaldi team doesnt see a need for unique features.
Now before someone says I have no idea what I'm talking about: I'm wrote a mail client from scratch roundabout 20 years ago. Only POP3+SMTP and standalone, not as a browser plugin (in that time, in the era of browser wars, there was no plugin API in Netscape and IE as we know today). After 8 weeks i had a mockup. 4 months later, I had a beta. Most of it was recycled code from other projects or third party code. But then I had no more time for it and not much later, M2 was introduced and was much better than my creature.
But, when I could write a mail client alone, a small team can do it too. If it was meant to be. But I think, it's not.
-
@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.
-
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.
-
@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.
-
@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.
-
-
@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.
-
@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.
-
@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?
-
@Codehunter It started with 2 (Jon and Geir Iversoy, 1995), and wound up with over 200 (2013).
-
@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