Hot off the presses! Google just released the latest future ex-api they will get bored of in a couple/few years and kill, along with any company that depends on it. #rememberthiscommentthen
Gmail API
31–40 of 147 posts
Re: Gmail API
#32I 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 comp…
The new API specifically recommends using IMAP for building a "full-fledged email client." I think you are misreading that statement.
Re: Gmail API
#33My killer app for this needs webhooks, or some sort of event notification when mail arrives. Bonus points for making that condition a stored procedure/filter. Until then I'll probably run out of "quota units" polling the thing..
You could probably have your mail pass through a non-gmail server like http://www.mailgun.com/ first
Re: Gmail API
#34Can't wait for the Emacs Lisp client library! (Wish I had time to work on that.)
Re: Gmail API
#35Nice, but I'm very reluctant to give any third-party access to my mailbox. Most sites I use let me reset my password by email, so this is like handing over the keys to the castle.
One of the advantages of this is that it allows finer-grained control than IMAP, so it can be used, e.g., for apps that can send mail (or create/read outgoing drafts) but cannot read incoming mail. So you can have at least some mail apps that don't require the "keys to the castle" that you are worried about.
Re: Gmail API
#36I 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 comp…
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.)
Re: Gmail API
#37Nice, but I'm very reluctant to give any third-party access to my mailbox. Most sites I use let me reset my password by email, so this is like handing over the keys to the castle.
One of the advantages of this is that it allows finer-grained control than IMAP, so it can be used, e.g., for apps that can send mail (or create/read outgoing drafts) but cannot read incoming mail. So you can have at least some mail apps that don't require the "keys to the castle" that you are worried about.
It looks like auth scopes allow to restrict to read-only already [1], but I would really love to be able to restrict to a specific label/subfolder. Would provide a good level of security without having to forward the email etc, plus labels can be applied afterwards without modifying an email.
Re: Gmail API
#38If they can combine this ease of accessibility for developers with a security model on the end-user side, I think it can be a solid win. I'd love to see granularity in what the API can access, for example, TripIt may request something like "Grant access to emails from the domain travelocity.com, usairways.com, etc.," and I can know with confidence that they will not have access to the rest of my inbox.
It doesn't have that level of granularity, just four auth scopes:
1) Full access to the account
2) Do everything but permanent deletes of threads and messages
3) Read everything, but no write access
4) Create/read/update/delete drafts and send messages/drafts, but no access to anything else
Finer-grained access (especially for reads, but there are some use cases for finer-grained sending controls, too) would be better, but this is, AFAIK, a step ahead of any other email API.
EDIT: source https://developers.google.com/gmail/api/auth/scopes
Re: Gmail API
#39Nice, but I'm very reluctant to give any third-party access to my mailbox. Most sites I use let me reset my password by email, so this is like handing over the keys to the castle.
Yep. It would depend how granular it is. I'd like to only allow access by sender domain or something like that. However - how many people trust our email to small web hosting companies? How much better is that? For example - many of my clients use the mailbox provided by Webfaction who I'm sure are beyond reproach but do I trust them any more than I trust a well known SASS company that integrates using the GMail API?
Granularity is the key here.
I run a small self-tracking service (zenobase.com), and would love to let my users pull in some "metadata" from their email (e.g. the number of messages in the inbox, or the number of messages sent by hour). But I don't want my users to trust me with unrestricted access to their email.
Re: Gmail API
#40I 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 comp…
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.