On Feb 8, 2017, at 2:26 AM, Yoav Nir <ynir(_dot_)ietf(_at_)gmail(_dot_)com>
wrote:
That’s good to know. I’m wondering if implementing a generic email client
(rather than a specific “gmail” or “live” client) isn’t becoming ever harder.
With so many older and newer services, a client has to support pop3, imap,
smtp, EWS, ActiveSync, and maybe a few of the others you mentioned. This
effort proposes to add yet another one.
The protocol and database backend parts of implementing a mail client are only
difficult in the sense that ActiveSync is not a standard. IMAP, SMTP and POP
protocol implementations are readily available. The problem is not that they
are hard to implement. It's that they don't work very well. SMTP works
great, don't get me wrong, but IMAP and POP both use the wrong data
abstraction, and consequently are very hard to get right, and generally aren't
gotten right.
So a new protocol that has the data abstraction right is actually a substantial
improvement. I don't know if that's the case with JMAP—if it's the same data
abstraction as IMAP, it's not worth bothering with, but that's something that
at least in theory can be discussed.
What JMAP does afford is the opportunity to have an embedded web client that
doesn't suck, and a way to escape it if you want something more stateful.
Doing IMAP in a web browser is painful. I've seen it done. It wasn't
pretty, and the company that did it corkscrewed in and left a crater. So
practically speaking, if you want to do email that way, you are already
implementing something like JMAP, but you are doing it by yourself, and it's
not standard, so your customers are stuck with what you did.
Even if the data abstraction is wrong in JMAP, you still get a substantial win
from that one improvement.