5 ms·

I like the idea of opening gmail up to developers via a public API, but I don't like that it comes at the cost of removing support for an open standard like IMA

I like the idea of opening gmail up to developers via a public API, but I don't like that it comes at the cost of removing support for an open standard like IMAP. I'm worried that API access could be cut back or eliminated entirely in the future depending on developer uptake, leaving gmail entirely inaccessible to third-party applications. Edit: I'm going off of this sentence: >It will replace IMAP, a common but complex way for applications to communicate with most email services, limiting the number of apps that can work with Gmail Maybe it's misleading, but it sounds like the plan is to drop support.

rwbt 12y ago
I don't think IMAP support is going away. This is just a better API for devs to create apps for Gmail.
duskwuff 12y ago
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.
- XorNot 12y ago
  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.
alooPotato 12y ago
I think its pragmatic, IMAP is just so painful. EDIT: and inefficient
eli 12y ago
The new API specifically recommends using IMAP for building a "full-fledged email client." I think you are misreading that statement.
- nnnnni 12y ago
  I read it exactly as you did. Hopefully they won't change that!
dragonwriter 12y ago
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.)
malandrew 12y ago
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.
- alex_duf 12y ago
  I've seen an application in production using e-mails as a message broker. It worked pretty well.
  - iLoch 12y ago
    Isn't there a lot more overhead with the headers? Neat idea though.
    - vidarh 12y ago
      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.
  - jlgaddis 12y ago
    You can still replicate Active Directory over SMTP.
  - vidarh 12y ago
    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.
ebbv 12y ago
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.
- dragonwriter 12y ago
  > 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.
- pjmlp 12y ago
  Because only Microsoft gets hate on HN.
- gregschlom 12y ago
  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.
  - calpaterson 12y ago
    Unsuited in what way? Can you go into more detail?
steveklabnik 12y ago
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.

rwbt 12y ago

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

duskwuff 12y ago

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.

XorNot 12y ago
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.

alooPotato 12y ago

I think its pragmatic, IMAP is just so painful. EDIT: and inefficient

eli 12y ago

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

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

dragonwriter 12y ago

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

malandrew 12y ago

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.

alex_duf 12y ago
I've seen an application in production using e-mails as a message broker. It worked pretty well.
- iLoch 12y ago
  Isn't there a lot more overhead with the headers? Neat idea though.
  - vidarh 12y ago
    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.
- jlgaddis 12y ago
  You can still replicate Active Directory over SMTP.
- vidarh 12y ago
  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.

ebbv 12y ago

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.

dragonwriter 12y ago
> 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.
pjmlp 12y ago
Because only Microsoft gets hate on HN.
gregschlom 12y ago
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.
- calpaterson 12y ago
  Unsuited in what way? Can you go into more detail?

steveklabnik 12y ago

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.