6 ms·

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

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.

jlgaddis 11y ago
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-email/ https://blog.fastmail.com/2014/12/23/jmap-a-better-way-to-em...
wtetzner 11y ago
Well, HTTP/2 with server push should handle the "keep a connection open" and "let the server push things to the client" issues.
rewqfdsa 11y ago
Because programmers graduating today literally can't imagine a world full of non-HTTP protocols.
_pmf_ 11y ago
> 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.
buster 11y ago
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.
wnoise 11y ago
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.
brongondwana 11y ago
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.
pjc50 11y ago
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.

jlgaddis 11y ago

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-email/ https://blog.fastmail.com/2014/12/23/jmap-a-better-way-to-em...

wtetzner 11y ago

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

rewqfdsa 11y ago

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

_pmf_ 11y ago

> 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.

buster 11y ago

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.

wnoise 11y ago

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.

brongondwana 11y ago

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.

pjc50 11y ago

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.