JMAP – an IMAP replacement
jmap.io
jmap.io
I tried finding more info on JMAP from fastmail by searching for "jmap site:blog.fastmail.com" (https://www.google.com/?gws_rd=ssl#q=jmap+site:blog.fastmail...) but they haven't written anything relatively new unfortunately.
By searching for "jmap site:edu" in Google, I found: https://cyrusimap.org/
Cyrus IMAP supports JMAP but I am unable to find any JMAP clients that are being used in production.
(I say half-hearted because when djb is enthused, the first people hear of it is a complete first draft of a server and a client...)
(If the Fastmail people are reading this, feel free to contact me.)
"Why use HTTPS/JSON? The short answer is it’s good enough, widely understood and it’s by far the easiest thing for developers to adopt. There’s support in basically all OSes and programming languages. It’s easy to read and debug."
Why not INI files, then, or a CSV, delivered over DNS? "Wide support and rapid adoption" is great if you're trying to make money, but not necessarily a great technical design framework.
The reason webapps work with HTTP/JSON is they had to. They were built on top of old standards which had to be backwards compatible, and they had to work around holes in the existing technology. So they took existing tech and extended it, and made it simple enough for everyone to adopt it warts and all, rather than improve it. We've been slowly patching its gross inefficiencies ever since.
An IMAP replacement does not have to work over a web platform, so it does not need this kind of unnecessary coupling of disparate, complicated standards to make it more clunky. But they're doing it anyway. So, why build a complicated new protocol on top of difficult, completely unrelated standards?
This new standard only exists as a vehicle for their own services and products, because they need other people to adopt it for it to make sense as a product they can make money on vs their competitors. They could have just worked with the industry on the next generation of IMAP, but that wouldn't be adopted "as quickly" to lock an industry into the model they are already developing.
You might see it as more clunky but I think it's great that the transport and security layer are bundled into something I already work with and know how to debug. I don't think the extra overhead is a concern these days. Most servers can handle that sort of load easily and most clients have not issue with HTTPS/JSON.
Here's a nice blog post about that: https://blog.fastmail.com/2014/12/23/jmap-a-better-way-to-em...
But. I don't think IMAP is the real competition here. This is, for most people, a solved problem, and a problem that's been solved by exchange and gmail.
So for better or worse, showing you're better than IMAP doesn't cut it. You have to show you're better than exchange.
One of the things I don't understand is why email protocols were allowed to languish for so long, making proprietary groupware suites practically mandatory for getting work done.
> You have to show you're better than exchange.
> making proprietary groupware suites practically mandatory for getting work done.
It's not proprietary groupware is why it's better than exchange. I'd argue that if you can get the same work done, you're winning.
you must not work enterprise much
I'm currently poking around the protocol, and thinking of implementing it into K9-mail (A popular android email client, that happens to be open source). I'm self-hosting my email already, and I'd really love to use this. It seems to fit much nicer into the current ecosystem than IMAP.
Open-source servers apparently exist (listed on the site).