Hopefully, next year there will be JMAP support for Contacts. As RFC drafts, there are already JMAP specifications for Files and Calendar...
But Gmail doesn't have "folders". They have "labels". I wont go into all the details about how Gmail labels work that frustrate and annoy me, but the point is that IMAP clients cannot see labels, they can't replicate it on the client end, etc.
This caused a legitimate problem at work when the finance dept. wants to use this service that reads emails to automatically scan invoices into their system and whatnot. They wanted to be able to only have a subfolder automatically imported into the program, because too many of the emails were not relevant to get imported, creating more work to clear them out.
We were not able to achieve a solution with a simple folder for the users to move emails into to get them imported. Instead, we had to set up a second email account specifically for this importing service, and whenever finance wants something imported, they forward the email to that second account.
I think the "NOT" slipped in there by accident.
It's not a feature originally built for labelling like Gmail, so it has a few complexities ("Servers MAY permit the client to define new keywords") and enough clients (especially mobile) that don't support it - but they could just like Thunderbird or some webmail clients.
I've used it basically exactly like Gmail labels for years on TB on desktop.
But you have to ask on that scale, what would it bring them other than change if everything already works fine?
Having implemented JMAP and IMAP protocols myself, I haven’t encountered a need in either protocol to send binary data to the server for sync/search operations that would require the server to perform expensive parsing.
JMAP offers many improvements, such as a stable messageId for each message and a state mechanism that allows the server to be queried for changes since the last saved state. This avoids the need for numerous IMAP SELECT commands per folder to check the state using CONSTORE/QRESYNC.
If CONSTORE/QRESYNC aren’t supported by the client, it results in very costly chunked queries just to verify if message flags are still the same.
The same applies to SEARCH—if a user has many folders, it requires multiple network hops to SELECT and query each folder. With JMAP, this can be done in a single API call.
IMAP is absolutely terrible on unreliable connections. A connectionless protocol based on HTTP would do much better in those conditions.
IMAP is ugly but that is all well understood.
Note I've designed and built a complex messaging system that runs over HTTP over unreliable connections and run it in production for 15 years so I know what can and does go wrong.
Popcorn at the ready.
To some degree, that isn't true anymore as of last week but of course, you meant when you used it, not generally: https://www.fastmail.com/blog/offline-in-beta/
Useless to me. Seriously.
I write a lot of email on planes and do a lot of email management.
All that works on the default Apple stuff as shipped other than account management. Using IMAP and iCal etc.
Does not Thunderbird work with Gmail/Microsoft/etc? Does not Apple's Mail.app?
And yet: at least as of a couple months ago, there isn’t actually any offline support! The Fastmail first party app does not work at all offline. Complete failure. Does not even try. Oh, and it has dramatically worse threading support than even Gmail or Outlook.
I don’t get it. POP3 is awful and kind of works offline. IMAP is old, clunky, and works fairly well offline. JMAP is supposedly the new hotness, but the paid first party experience will not even try to load offline. This is table stakes! Eudora could do this. Every version of Outlook ever could do this. Thunderbird can, and always could, do this. The usual command-line clients work offline if configured appropriately. Heck, Google went above and beyond and made Gmail’s webmail work quite well offline if you care to set it up, and I think they did a bunch of early work on service workers to make this possible. Fastmail, please stop pitching your fancy protocols until you can get your clients up to the state of the art as of twenty to thirty years ago.
The app is ready for offline use, but I don't want to implement it without 'full text search.' I plan to use SQLite FTS5. My initial tests with search show that offline search is storage-expensive, which could be problematic for mobile devices. So, the edge cases have started to appear. But it's the most requested feature, and the most interesting/challenging to me :)
Or even worse, sometimes I look at some email in Mail and it’s there, and then hours later, while on bad network conditions, I look at it again and see “This email has not been fetched from the server. Download?”, which then just hangs.
I have a 1TB iPhone and a 2TB iPad. My main Gmail account is not large by any means - ~50k emails and 5GB space. Even though I have all this space on my iPhone/ipad available and willing to commit a bunch of it to email with all attachments and full text index, there seems to be no way to do it.
The Gmail app has a slider for “days of mail to sync”, but the max is 90 days, and not “All time” like one would expect. Anyways, good luck with Mailtemi!
It would be great that the two big email providers (Google and Microsoft) implemented and supported it.
It would make so easier and reliable to have a single client that works really well across personal and business email accounts, for example.