[jstedfast]

An HTTP-based IMAP replacement makes me want to put a bullet in my brain.

IMAP is actually really good for the most part. It just has a few legacy warts (like EXPUNGE notifications being index based instead of UID-based), but a lot of the newer extensions fix these problems.

The CONDSTORE and QRESYNC extensions drastically simplify re-synchronizing the client and server and have been around for quite a few years at this point.

Honestly, if I was to design a brand new protocol for mail, it would be very close to what IMAP is today and just make a number of the newer extensions mandatory (UIDPLUS, LITERAL+ with Google's caveat for APPEND, NAMESPACE, SPECIAL-USE, SASL-IR, CONDSTORE, QRESYNC, perhaps a few others). I'd also include IDLE, but not as a distinct command - rather just have it always-on (at least as long as a folder is selected).

The #1 issue most developers have with IMAP is that every server implements a different subset of extensions. This isn't an IMAP-specific problem, however, it's just what happens to any protocol that gets as much adoption as IMAP and lives as long as IMAP has lived. There will always be new extensions for any protocol to improve upon it in various ways just like no framework API is ever complete.

Forcing all mail clients to go through HTTP for mail access is just retarded. It's depressing that so many people love the idea of using HTTP for everything. Honestly, wtf?

[brongondwana]

I've worked on an IMAP server for a long time.

HTTP is just one potential transport for JMAP, the spec itself is:

* heavily based on IMAP concepts, borrowing particularly from CONDSTORE and QRESYNC but also taking the better bits from Card/CalDAV around opaque syncToken rather than forcing a sequential modseq, because that's harder to cope with distributed systems on the server with exact ordering * designed a lot more around server side sort/search, because UID ordering sucks in various ways - try moving some messages into your INBOX and noticing that iOS mail displays them in APPEND order rather than date 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 a regular datastructure rather than the abomination which is IMAP. Things like system flags starting with a \ which makes them not an atom, yet sent like an atom without quoting.

In general, IMAP has many things which are done implicitly rather than explicitly, which add cost that you can't avoid paying at both ends, even if you don't want it. Oh yeah, and it's really quite chatty. We're 280ms away from our server, so we really notice the chattyness. 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.

JMAP is a batch protocol that happens to be easy to implement over HTTP.

[jstedfast]

> * designed a lot more around server side sort/search, because UID ordering sucks in various ways - try moving some messages into your INBOX and noticing that iOS mail displays them in APPEND order rather than date order.

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")) "<[e-mail]>" "<[e-mail]>") 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: "[e-mail]"}], sender: [{name: "Example Sender", email: "[e-mail]"}], replyTo: [{name: "Example Reply-To", email: "[e-mail]"}], to: [{name: "Example To", email: "[e-mail]"}], cc: [{name: "Example Cc", email: "[e-mail]"}], bcc: [{name: "Example Bcc", email: "[e-mail]"}], inReplyTo: "<[e-mail]">, 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?

[brongondwana]

You put a lot of effort into your response, and I appreciate that.

But hey - that was a 36 message folder in that video. Show me an IMAP client that would do better and I'll be sufficiently impressed. They don't exist, because you can't do that.

I can show you, right now, a 500,000 message view across multiple folders infinite scrolling with JMAP and I can jump to the middle of that view and load a screenful of messages.

You CAN NOT do an IMAP sort without fetching one record for every message in the folder. If you have a million messages in a folder (yes, we have customers who do that) then you need to fetch a million records.

QRESYNC does improve matters a lot - except almost nobody implements it (we do: I fixed the initial implementation to be exactly correct in all the edge cases) - and JMAP's synchronisation is based on QRESYNC with extra protections against a flood of traffic if the server has many more changes than you expected.

I suspect your allergy to all things JSON and HTTP has coloured your attitude to the protocol, which is a pity.

(IMAP isn't a batch protocol - it supports pipelining, and that's good - you'll notice we also tag commands in JMAP)

Anyway, I look forward to your demonstration of an IMAP client fetching and preparing a view of a 36 message folder alongside our web interface loading the same folder from scratch, no local data present.

Until then, screw your calling bullshit. Go get yourself an iPhone (or ANYTHING with an IMAP client on it) and create yourself a FastMail free trial and reproduce the scenario in the video yourself. You don't need to take my word for it, it's trivial to recreate.

Basically, put up or shut up if you think IMAP is so good. If you think we're missing an IMAP extension that would make your demo work better, let me know and I'll implement it. If you need more than a month, let me know and I'll extend your trial as long as you like.

[jstedfast]

It'll take me longer than a month to implement my own IMAP client to do things efficiently.

As it just so happens, the company I work for is having a "work on anything you want as long as it dog-foods our products" week next week and I was already planning on writing an IMAP mail client for iOS that didn't suck. Unfortunately, due to the complexity of writing a mail client, I doubt I'll finish in a week.

That said, thinking about the problem a bit more since last night, there's 1 major performance bottleneck in the IMAP protocol for this particular use-case but it could be solved with an extension to SORT.

So, as I'm sure you know, the SORT command (even with ESORT) only allows returning MIN, MAX, MODSEQ, and COUNT (from memory there might be 1 more, but I forget what it is) in addition to the matching UIDs/indexes. It's not that these aren't useful, but to optimize the "open a mailbox for the first time and display a message list to the user in the fastest way possible", they aren't all that helpful. Instead, what is needed is something more akin to the following (made up) command:

TAG001 UID SORT RETURN (OFFSET 0 LIMIT 50 FETCH (ENVELOPE FLAGS ...)) UTF-8 REVERSE DATE ALL

And this command could return untagged FETCH responses with the requested info - since we'd need a way to determine order, we could say that the FETCH results should be in the order requested or we could also have it return an untagged ESEARCH response like extended SORT commands do now to define the UID ordering.

In other words, make it so that SORT (and SEARCH, for that matter) return the information that we ultimately care about rather than the list of UIDs which we then would have to use to fetch the information we want.

(in hindsight, this is probably what you meant by "chatty" whereas I interpreted it to mean "verbosity" last night)

Basically, make it a bit more SQL-like.

Problem solved.

[brongondwana]

Yeah, OK - so you're doing what JMAP does but with a ton of search extension which STILL don't get you cross-folder support. Nice, problem solved - except you don't have a month to implement a good IMAP client, and neither does anyone else in the world.

Has ANYONE ever implemented a good IMAP client, in your opinion? If not, why not?

(JMAP is basically IMAP but more SQL-like, and without a bunch of custom syntax, yay)

[jstedfast]

I think plenty of people have time to implement a good IMAP client, just not me because I have a job that is completely unrelated to writing mail clients.

[jstedfast]

> I can show you, right now, a 500,000 message view across multiple folders infinite scrolling with JMAP and I can jump to the middle of that view and load a screenful of messages. You CAN NOT do an IMAP sort without fetching one record for every message in the folder. If you have a million messages in a folder (yes, we have customers who do that) then you need to fetch a million records.

If I've got the sort order (from a UID SORT REVERSE DATE command), and a user jumps to the middle of the list, I can FETCH just the visible subset of messages by calculating what the UIDs would be and then doing:

TAG UID FETCH <visible-uid-set> (ENVELOPE FLAGS ...)

I'm not sure why you think you'd have to issue a FETCH command for each message individually.

[brongondwana]

Yeh, no shit - but you need to either have downloaded EVERY UID in that sort order (no updates either - if ANYTHING changes in the folder while you were disconnected you need to re-fetch the entire sort list) or you need sort extensions which don't even exist yet.

[jstedfast]

Then why did you say you couldn't if "yea, no shit" you knew you could?

If you've already grabbed ENVELOPE info for all of the older messages (i.e. all of the messages from a previous session), you can just download the ENVELOPE info of new messages and then sort locally.

I mean, if only a few messages have arrived since the previous session, it's probably faster to grab the ENVELOPEs and then sort locally.

If there's a lot of new mail, it might be more efficient to sort server side and just fetch the ENVELOPEs for the messages in view and lazy-load the rest when the user is idle (which is most of the time).

A dead-simple heuristic would be if the number of new messages is fewer than the number of messages you can show in a list, then it's probably not worth doing server-side sorting, right? Does that make sense? Especially as mobile devices get more and more powerful. You just need to design your sqlite database such that it's setup to do optimal sorting by whatever sorting method you are using (by date should be easy, right?).

I've actually done this sort of thing before (although not with IMAP), so I know it's doable. It just takes thought to design it and time to implement it.

I've studied the IMAP specs in my spare time over the past year or so and know them pretty well and I'm confident I could get good results if I had the time to implement it, but it's not like anyone in the world could implement a solid IMAP client in a week or even a month working on it full time and seeing as how I couldn't spend full-time working on writing a mail client due to the fact that I have a job that doesn't involve me writing said mail client, I don't see how you could possibly expect me to implement one in a month.