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

[brongondwana]

http://trojita.flaska.net/

two developers, 5 years, not yet feature complete - but it's the closest thing to someone attempting to write a really good IMAP client based on the RFCs, and they've been active in mailing lists and IRC too.

Funny how nobody has actually built this mythical IMAP client you say is so easy.

[jstedfast]

Wow, way to attack a straw man there.