Unfortunately it includes my biggest gripe about IMAP -- the requirement that messages are given a server-side message number. Maybe breaking with IMAP on this would make interop too hard though.<p>This requirement is convenient for the client but makes implementing robust servers harder than it need be. If instead each message was identified by a {timestamp,UUID} tuple then multiple MX servers could do final delivery to an eventually-consistent shared store. The requirement for strict, durable message ordering is the one thing that forces hard synchronization among multiple machines doing delivery.<p>POP3 actually made a step this direction with the common "UIDL" extension; IMAP4 felt like going backwards on this.<p>While I'm on the subject, another less-common POP3 extension I liked was "XTND XMIT". This gave a simple way for the POP3 client to send mail; sadly it never really caught on in favor of just using SMTP submission. Originally though this only worked OK because SMTP was open-relay. Once spam put an end to that it became complicated to send a message when accessing your mail remotely. Then to solve <i>that</i> problem we had to graft an auth layer on top of the existing SMTP protocol and upgrade all of the clients and servers to support it. If only "XTND XMIT" had won in the beginning everybody would be submitting outgoing mail over that already-authenticated channel and so much work could have been avoided.<p>So anyway, those are my two requests for any "IMAP killer": allow the server to use unique (but non-sequential) IDs for messages and provide a way to submit outgoing messages over the same channel.
HTTP itself has an overhead, I'm skeptical changing a persistent IMAP connection into a request/response model with a different serialization format is going to be more efficient, especially given compression (like COMPRESS=DEFLATE)<p>IMAP4rev1 is one thing, but there are many extensions supported in modern imap servers to speed up syncing and mailing, like CATENATE/BURL/CONDSTORE/MULTIAPPEND/MOVE/etc<p>Granted, the IMAP protocol is pretty hairy and difficult to work with. On the other hand, there's a huge ginormous deployment of it on the client and server, and the IETF WG behind it. I doubt JMAP will replace it anytime soon unless the WG itself takes up the issue. And given the neckbeards there ;-), some of whom have been working in IMAP for decades, you face the same opposition to change as those trying to legalize drugs or gay marriage. ;-)<p>We're still trying to get IPv6 deployed!
This is similar to what we're using at FastMail for our web interface, but simplified and made a bit more generic based on our experiences over the past year.<p>Our plan is to port our web interface across to this spec and implement both a direct backed in Cyrus IMAPd and a standalone implementation which can proxy for existing IMAP servers.
Interesting step, but the decisions taken around concurrency seem to assume small-scale, single-user use cases only. I would be the first to admit I haven't given this enough thought yet, but to me it seems that a global lock and MODSEQ make distributed usage etc. very difficult. Isn't this a step backwards?
Call me curmudgeonly, why replace a protocol that works...instead roll up a library to provide the functionality...<p>Those things called standards generally find their way through bodies like the IETF. Maybe I missed it while reading on my phone, but I don't see this submitted as an IETF draft...
Does JMAP have an equivalent to IMAP IDLE? I.e. the ability for the server to notify the client when an email arrives. This means client's don't need to poll, and messages are seen instantly.<p>For me instant notification of inbound message is a must-have.
Interesting. What is the reason for grouping method calls together? Is this to reduce the number of requests sent to the server? If not, is there no way of providing a higher level operation instead of bundled discrete operations?<p>In any case, I think you could have something a lot closer to REST, even if you carry on with grouping calls together.<p>Something like:<p><pre><code> [
[ "GET", "/messages", { "search": "foo" }],
[ "GET", "/mailboxes", { "etag": "bar" }]
]
</code></pre>
Obviously, you're not limited to HTTP verbs if you do it like this, but it's a familiar metaphor.
IMAP is mostly slow as hell when dealing with large mailboxes. For example fetching the 10 most recently updated threads (for a sane definition of what a thread/conversation is, which imap doesn't deal with at all) is insanely slow. It entails scanning the whole mailbox trying to figure out what the threads are and when someone last posted to them. Not fast when you can have millions of mails in a mailbox. Is that the kind of problems JMAP might solve?<p>Also interested in hearing if you know anything about GMail's json api? Surely they must have something similar to JMAP which their web client is using even if it the api is proprietary?
I'm a big proponent of everything-behind-http because of the way it introduces a common language for integrating disparate services.<p>However! as someone who has had to debug some particularly gnarly email issues in the past I really do quite like the ability to telnet into an IMAP server to dig around. I also have an appreciation of some of the more horrific things that can go wrong...<p>So my point is that I'm not sure I agree with "generally much easier to work with than IMAP" - there's two types of "working with". One is building a new client/server from scratch - I'd agree this might be easier, but not something that is done <i>that</i> often. The other is being able to quickly investigate issues with hand-crafted queries, and unfortunately I'd say a simple plain text question-answer interface is better - and here IMAP wins.<p>Maybe I'm just getting old - it's probably true that almost everyone is happier with HTTP than "telnet-able" protocols (SMTP, IMAP, Redis, etc.) nowadays.
I maintain an imap client library for PHP ( <a href="https://github.com/tedivm/Fetch" rel="nofollow">https://github.com/tedivm/Fetch</a> ), which is far more painful than it really should be. I really am happy to see attempts at a more modern approach.
Any new access protocol for mail should be designed to work over persistent secure socket, not over HTTP. Additionally, there should be a minimum of work imposed on the server by the client.