Whether they drop support or not, clearly their idea here is to replace it.

Replacing globally supported open standards with proprietary APIs is one of the things people hated about Microsoft in the past.

Why does Google seem to get a pass from so many developers for this type of behavior? Or worse, get applauded for it?

If the argument is IMAP is out of date and crappy, then OK, let's make a new standard. Unilaterally making your own API is not the way. Unless you don't care about anyone but yourself.

> Whether they drop support or not, clearly their idea here is to replace it.

Its clearly their idea to replace it for some use cases for which IMAP's design is completely unsuited. Beyond that seems to be speculation.

> If the argument is IMAP is out of date and crappy, then OK, let's make a new standard. Unilaterally making your own API is not the way.

Actually, unilaterally creating your own API, getting some real use and experience with it, and refining it and submitting it for standardization is exactly the way that useful new standards usually get created. Attempts at creating standards not based on existing unilateral APIs often result in things that no one ever implements, like XHTML 2.

Having spent one year of my life trying to replicate Gmail's interface in a desktop app through IMAP (www.betterinbox.com), I can say with confidence that IMAP is completely unsuited for the Gmail paradigm. If we had this API back when we were working on BetterInbox in 2011, our lives would have been much easier.

Unsuited in what way? Can you go into more detail?

Because only Microsoft gets hate on HN.

It doesn't sound as though they're removing IMAP. It's still the recommended API for mail client applications. This API is a new, separate option for applications that don't need access to all your mail.

Gmail don't implement IMAP properly anyway - the IDLE command in Gmail doesn't provide notification of changes in the number of unread messages, just the existence of new ones.

It was quite a shock to find when I stopped hosting my email via GetMail/Dovecot that my read messages wouldn't automatically propagate across my devices until I did a manual poll. Gmail seems to use some HTTP API for this rather then following the standard.

The new API specifically recommends using IMAP for building a "full-fledged email client." I think you are misreading that statement.

I read it exactly as you did. Hopefully they won't change that!

It now says

> Note: The Gmail API should not be used to replace IMAP for full-fledged email client access. Instead, see IMAP and SMTP.

Note the NOT.

TBH, I've never understood why more people didn't explore the multipart content type feature of email to extend email. It's typical to have plaintext and html in the same email, but why no JSON using a well defined and published JSON-schema.

I'm pretty sure that absolutely nothing is preventing this, and you could start sending emails with JSON inside right now. The hard part is probably finding something meaningful for it to do.

Serious question: What is the use-case for email as a server communication protocol rather than say HTTP/s ?

Is it to bypass firewalls in some way ?

Email allows someone to send me data, as opposed to HTTP/S which targets servers. Adding structured data to emails could allow natural language communication to have a machine readable view of the communication. And there's probably a lot more uses.

You'd still have the option to use WebSockets or Ajax-polling.

I've seen an application in production using e-mails as a message broker.

It worked pretty well.

I've done that twice: First time was when we built a demo registrar platform for ".name". We used Qmail with some custom bits and pieces to distribute messages that were used for things like live updates of the primary DNS server, live updates for a web forwarding service etc. A couple of the guys took the idea much further, and implemented a small library to do things like queue browsing via POP3.

The nice thing was all the existing tools that works well with various aspects of e-mail, and the great ease of introspection and testing.

The second time I did it was at Edgeio, where I initially used it to get a prototype of our blog feed retrieval / indexing pipeline up and running quickly. Though we relatively soon replaced it with a homegrown Stomp server, mostly because a lot of the stuff we were doing didn't need the delivery guarantees of e-mail, so we used in-memory queues for a lot of stuff.

It works great for some workloads, and it's a very easy way of prototyping things that makes it easy to debug message flows etc.. The state of open source message brokers have drastically improved since the times I did it, though - the first time we did it was back in 2002 or 2003.

Isn't there a lot more overhead with the headers? Neat idea though.

Depends on your messaging volume and typical message size. For some types of apps it won't matter because the volume is small; for others it won't matter because the payload is huge. But you get battle-tested federation, scaling, server discovery etc. nearly free.

You can still replicate Active Directory over SMTP.

They recommend IMAP for full clients. The new API will replace IMAP for a wide variety of use cases, though (since IMAP was the only choice before it was available.)

I don't think IMAP support is going away. This is just a better API for devs to create apps for Gmail.

I think its pragmatic, IMAP is just so painful.

EDIT: and inefficient