Hacker News Reader

Comment by teacup50 | Hacker News Reader

Why not extend IMAP? It is by definition highly extensible, and unlike JMAP, it's not wedged into complex poorly suited protocols like HTTP.

Clients leave IMAP ports open indefinately; IMAP IDLE provides push e-mail over this mechanism.

Reading about JMAP, this just seems like adding unnecessary web overhead and complexity to an already complex problem space.

View on HN

FastMail's "why" is better explained in a post from last year, "JMAP -- A better way to email" [0].

[0]: https://blog.fastmail.com/2014/12/23/jmap-a-better-way-to-em...

So we do that too - indeed I've done most of the work getting the Cyrus IMAPd server support of IMAP to the level of compliance that it has today, and am still involved in the standardisation battles. But I see from the responses to this comment that it's easier to make snarky comments on the internet than to understand where IMAP just doesn't do what we needed from a protocol, and why we designed JMAP.

The thing to replace is not so much IMAP (which has its own awfulness of implementation) but RFC822-format mail. It looks easy to parse but isn't, giving rise to bugs. Especially if you step outside the ASCII character set. How many of you have an email with a spurious `> From` in the middle because that has been escaped wrongly by something?

Besides, JMAP could be consumed directly by web apps.

While I think extending IMAP is the better solution, it is already too complex, as many clients and servers treat things just slightly different enough to be really annoying.

It's just a smart move to have the API your webmail uses be a "standard"...

I don't understand why i should implement Fastmails web API, when there are several major protocols that are supported by a huge ecosystem already: IMAP, CalDAV, CardDAV.

Well, HTTP/2 with server push should handle the "keep a connection open" and "let the server push things to the client" issues.

> It is by definition highly extensible, and unlike JMAP, it's not wedged into complex poorly suited protocols like HTTP.

Why building on mature concepts that have proven themselves in practice over several decades? It's much more in line with the current web culture if smart rockstar developers half-assedly cobble together a RESTful shit fest.

Because programmers graduating today literally can't imagine a world full of non-HTTP protocols.

Reply on news.ycombinator.com