Live data from Hacker News

Gmail API

developers.google.com

71–80 of 147 posts

Re: Gmail API

#71

I'm not sure what this API enables that can't be done over IMAP. IMAP may not be as familiar as JSON-over-REST, but it's supported by virtually all mail clients and providers, which makes it about as open as you can get. Already the Gmail IMAP implementation is non-standard in a number of annoying-but-workable ways. I've been suspecting for a while that they're going to kill it or lock it down, the way they did for X…

Just based on a glance of the documentation, you can permanently delete emails using this, I don't think you can do that with the IMAP interface for gmail, but I'm not 100% sure on that.

Re: Gmail API

#72

We (Streak, YCS11) have been using this API for a few days to build our email snoozing feature ( https://www.streak.com/email-snooze-in-gmail ). The API is really nice to use and makes interacting with Gmail way easier relative to IMAP. I'm surprised they don't recommend using this API to build full email clients. I fully expected that to be one of the core use cases. The reason its hard (currently) to build a mail c…

Seriously, I'm not trolling - why would you want to snooze an email (hide it from inbox and have it come back later - I had to go look it up)?

Apart from that I like the API idea - I have been beta testing my own personal document scanner - I email myself photos of bills and receipts and file them under the subject line (ie file-as bills.electricity) - it beats the hell out of a document scanner I never used.

Anyway I was going to link it to Evernote but I just don't use Evernote enough to justify it

Re: Gmail API

#73

We (Streak, YCS11) have been using this API for a few days to build our email snoozing feature ( https://www.streak.com/email-snooze-in-gmail ). The API is really nice to use and makes interacting with Gmail way easier relative to IMAP. I'm surprised they don't recommend using this API to build full email clients. I fully expected that to be one of the core use cases. The reason its hard (currently) to build a mail c…

> I'm surprised they don't recommend using this API to > build full email clients. I fully expected that to be > one of the core use cases. I didn't see today's API announcement, but I'd be surprised if they wanted to encourage that. Similar to how Twitter doesn't want you to write full-fledged Twitter clients. If we write full-fledged Gmail clients, won't they miss out on the ad revenue? Maybe not; maybe they're jus…

> "... won't they miss out on the ad revenue?"

There's already a setting they lets you turn off ads. In any case, revenue from those ads is probably incomparable to the data-mining which they can then use to show you ads elsewhere.

Re: Gmail API

#74

We (Streak, YCS11) have been using this API for a few days to build our email snoozing feature ( https://www.streak.com/email-snooze-in-gmail ). The API is really nice to use and makes interacting with Gmail way easier relative to IMAP. I'm surprised they don't recommend using this API to build full email clients. I fully expected that to be one of the core use cases. The reason its hard (currently) to build a mail c…

Seriously, I'm not trolling - why would you want to snooze an email (hide it from inbox and have it come back later - I had to go look it up)? Apart from that I like the API idea - I have been beta testing my own personal document scanner - I email myself photos of bills and receipts and file them under the subject line (ie file-as bills.electricity) - it beats the hell out of a document scanner I never used. Anyway…

> Seriously, I'm not trolling - why would you want to snooze an email (hide it from inbox and have it come back later - I had to go look it up)?

Example that happened to me yesterday: a colleague asks me for a piece of information that I know I can find in a book at home, but I'm at work. I snooze the email so that it doesn't fall at the bottom of my inbox, and so that it gets redelivered when I'm home and can access the book.

Re: Gmail API

#75

We (Streak, YCS11) have been using this API for a few days to build our email snoozing feature ( https://www.streak.com/email-snooze-in-gmail ). The API is really nice to use and makes interacting with Gmail way easier relative to IMAP. I'm surprised they don't recommend using this API to build full email clients. I fully expected that to be one of the core use cases. The reason its hard (currently) to build a mail c…

Seriously, I'm not trolling - why would you want to snooze an email (hide it from inbox and have it come back later - I had to go look it up)? Apart from that I like the API idea - I have been beta testing my own personal document scanner - I email myself photos of bills and receipts and file them under the subject line (ie file-as bills.electricity) - it beats the hell out of a document scanner I never used. Anyway…

> why would you want to snooze an email?

I use my Gmail inbox as sort of a todo list. If a conversation is in my Inbox, it needs attention from me - I need to do some work related to it, reply to it, forward it, etc. Once I'm done with an email thread, I immediately archive it.

If you use this workflow (many do), snoozing an email is useful. I use it primarily for threads where I'm not able to reply and provide information immediately (so removing it from my inbox until I can reduces distraction), and for threads where I'd like to follow-up in a few days, if for example I don't get a reply.

Re: Gmail API

#76
post #60

Earlier quoted context omitted.

Unfortunately to snooze an email we need to be able to read the message and reinsert it. That requires full read/write permission. If we instead just replied to the thread, we could probably get away with just read permissions.

Is it possible to have full read/write permission but no communication with the outside world? Presumably, this would involve denying the ability to send emails and denying various forms of network access.

The API that launched today is just a backend API, so by definition your email data is accessible to the application on their servers.

You may be confusing how Streak works, where we have a browser extension that runs inside your browser, but our backend is the one doing the snoozing.

Re: Gmail API

#77
post #22

It would take something pretty amazing for me to allow anyone access to my gmail account. LinkedIn definitely made me skeptical on allowing even trustworthy-seeming companies access to my contacts.

> LinkedIn definitely made me skeptical on allowing even trustworthy-seeming companies access to my contacts.

Trustworthy-seeming companies like, say, Google?

Re: Gmail API

#78
post #18

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

The quotas are per user. So you can poll the /history endpoint per user. But yes, this isn't very efficient.

Re: Gmail API

#79
It's high time that we get user-controlled sandboxes that could enforce additional security restrictions and are application-transparent. If a third party app requires access (R/W) to my Google Drive files, I should be able to limit said access to a single folder, for instance, and any other content should simply be invisible to it. These restrictions should be tuneable at any time (before and after app install) and there should be visualization tools to control their effectiveness.

Re: Gmail API

#80
post #74

Earlier quoted context omitted.

Seriously, I'm not trolling - why would you want to snooze an email (hide it from inbox and have it come back later - I had to go look it up)? Apart from that I like the API idea - I have been beta testing my own personal document scanner - I email myself photos of bills and receipts and file them under the subject line (ie file-as bills.electricity) - it beats the hell out of a document scanner I never used. Anyway…

> Seriously, I'm not trolling - why would you want to snooze an email (hide it from inbox and have it come back later - I had to go look it up)? Example that happened to me yesterday: a colleague asks me for a piece of information that I know I can find in a book at home, but I'm at work. I snooze the email so that it doesn't fall at the bottom of my inbox, and so that it gets redelivered when I'm home and can access…

Hypothetically, wouldn't really aggressive archiving accomplish the same task?

Have a 0-email inbox, and if you get something that you can't address immediately (but you can take care of later in the day), then you leave it in the inbox. In the meantime, anything you can act on in some way gets acted upon and then archived. By the end of the day you would ideally have just that email in your inbox (and even in a realistic world you might have a few tasks lingering in your inbox, but few enough that you can glance and see that "task" still there). Check your email at the end of the day and act on the things you needed to postpone for whatever reason (as well as pruning emails loitering in the inbox).

This requires, as previously said, really aggressive archiving, but since there's no difference between inbox and all-mail as far as I know (unless you use it as a search operator e.g. "from:friend@university.edu label:inbox"), it wouldn't be that big a cost (except that you would have to remember to archive or go through later and archive stuff).

I had been doing this somewhat organically for a while - tagging emails that didn't get filtered automatically and archiving them when there was nothing more for me to do with them - but when I disabled all of my filters (a misguided experiment I don't recommend anyone attempt) I stopped.

Post reply on HN