FastMail gains push notifications in iOS Mail.app, joining only Yahoo and iCloud

Why not just sort the messages? Just because iOS Mail shows the message in APPEND order doesn't you have to show them in that order. You would expect to see them in APPEND order if you are listing them in APPEND order.

As I'm sure you know, IMAP also has server-side SORT extensions. I will agree that they could be expanded a bit, but you can do client-side sorting just fine (and in fact need to if you want offline support). JMAP doesn't fix that.

SORT is really only needed on the server side for calculating which subset of messages to FETCH summary information for (to display in your message-list) if you are incrementally displaying messages as the user scrolls and you have a sort-order applied that isn't "APPEND order".

> * connectionless / stateless as far as possible, because connections drop in the IMAP world, particularly in mobile, and the cost of a new SELECT is high, even with QRESYNC. It still has to create a COW view of the message space because it has to keep message numbers that don't track EXPUNGEs just in case the client wants to run a pipelined command.

It's really not that bad.

I already mentioned the EXPUNGES being tied to sequence id's (aka indexes) as being a wart, but IIRC a newer extension replaces EXPUNGE events with VANISHED (I think it was CONDSTORE or QRESYNC) which uses UIDs and vastly reduces the chattyness of a large number of messages being expunged because it gives has a uid-set argument rather than getting 1 EXPUNGE event per message.

You argue that a stateful protocol is bad because it forces the client to re-sync with the server by re-SELECTing the folder and that it is slow even with QRESYNC. Okay, so.... what? A stateless protocol means that new messages can't arrive if I get momentarily disconnected? And no other client can change flags on messages while I was momentarily disconnected?

That's ridiculous. You need to re-sync even with a stateless client to make sure your local mirror is identical.

Sure, with a stateless protocol you don't need to do that, your client could blissfully ignore the fact that another client could have changed something, but then again, you could do the same thing with IMAP - nothing forces you to have to do anything more than re-SELECT a folder and just blindly assume everything is identical to where you left it when you got disconnected. It's foolish to do so, but it's foolish to do so even with a stateless protocol...

> Go watch the video at http://jmap.io (recorded in Australia against a server in New York) and tell me you could do that via IMAP.

Okay, I watched the video. The IMAP client on the right was fetching far more information than it needed to which is why it was so much slower. You are comparing apples to oranges.

What do I mean by that? Well, it was pretty clear that the IMAP client was fetching information for far more messages than just the 5 or 6 that it was showing on the screen which is completely unnecessary. The "snippet" portion is slow, yes, because unfortunately right now, the client must wait for the initial FETCH request to return the BODYSTRUCTURE of all of the messages so that it can figure out which MIME part contains the message text and then issue FETCH requests for each of the messages one at a time (which is why you see each snippet load individually).

There is a current discussion on solving this problem with a SNIPPET extension for IMAP so that the client could request it in its initial FETCH request to get the summary info for the messages it will be displaying on the screen.

A lot of IMAP clients are extremely inefficient in the requests that they make and the fact that very few make use of PIPELINE'd commands.

> JMAP is a batch protocol

IMAP is also a batch protocol.

Let me ask you this: you say that IMAP is really chatty, and I will agree that some parts of it are, but fetching summary information needed to populate a message list is really not that bad.

Let's take a look at a FETCH response for a single message:

* 1 FETCH (UID 1 ENVELOPE ("Fri, 17 Jul 2015 10:49:03 -0400" "This is the subject" (("Example From" NIL "from" "example.com")) (("Example Sender" NIL "sender" "example.com")) (("Example Reply-To" NIL "reply-to" "example.com")) (("Example To" NIL "to" "example.com")) (("Example Cc" NIL "cc" "example.com")) (("Example Bcc" NIL "bcc" "example.com")) "<in-reply-to@example.com>" "<message-id@example.com>") FLAGS (\Seen \Draft \Answered \Deleted))

Now let's take a look at what this would look like in JMAP:

{ messageId: "f123u457", date: "2015-07-17T10:49:03Z", subject: "This is the subject", from: [{name: "Example From", email: "from@example.com"}], sender: [{name: "Example Sender", email: "sender@example.com"}], replyTo: [{name: "Example Reply-To", email: "reply-to@example.com"}], to: [{name: "Example To", email: "to@example.com"}], cc: [{name: "Example Cc", email: "cc@example.com"}], bcc: [{name: "Example Bcc", email: "bcc@example.com"}], inReplyTo: "<in-reply-to@example.com">, isUnseen: false, isDraft: true, isAnswered: true, isDeleted: true }

This is longer than the IMAP response!

Do you see why I called bullshit on your video comparison? It was obvious that your example IMAP client is purposely inefficient to make JMAP look good.

But let's ignore that for a moment... let's pretend JMAP is all that and a bag of chips.

What now? Since IMAP with all of the latest extensions to optimize/fix all of the problems with the original protocol have been around for years and yet many servers still do not implement them (if they did, there wouldn't really be a need for JMAP), what makes you think mail hosts will suddenly jump at the chance to implement a whole new protocol when they couldn't be bothered to implement existing extensions that would have drastically improved the user experience for their customers?