Gmail API
developers.google.com
developers.google.com
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 client using the API is that call to list the threads in your inbox or any other label doesn't actually return the messages in those threads. So its hard to show the people that are on the thread as well as some of the timestamp. If they added some more summary data to the thread object, I could see this becoming feasible.
If we instead just replied to the thread, we could probably get away with just read permissions.
Presumably, this would involve denying the ability to send emails and denying various forms of network access.
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.
I didn't think much of it, until I noticed access to her Gmail from Japan I seem to recall ( we are in Western Europe ).
Streak was installed into her account.
I have no idea what someone can do who has access to the Streak account. I just removed the permissions.
It costs $30/yr for the high-end service but send me a note and I'll give you a link to signup for free.
Plus our snoozing functionality is 100% free, no matter how many you schedule, or how long it's for :)
Oh, and you can see/edit/manage your snoozed emails all from right within Gmail.
And we also have the "Awaiting Reply" view that doesn't require you actually DO anything, other than send out emails. We show you a custom list of the last 20 emails you've sent that don't yet have a reply.
edit: added more about what features we have
Free to use: http://www.pfalke.com Open source: https://github.com/pfalke/returnx
> 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.
If we write full-fledged Gmail clients, won't they miss out on the ad revenue? Maybe not; maybe they're just glad to tie us to their service and data-mine our emails even if we're not using Google's web client.
Still, I'd be scared of basing a lot of work around this API, since they have a history of deprecating and discontinuing things in the past...
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.
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
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.
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.
Agressive archiving and postponing emails aren't mutually exclusive. They complement each other really well.
[edit] It also reduces stress. Some things can be dealt with until the evening, or tomorrow, or the weekend. It's really nice not having to pick though a middle of things that need to be done later and now and be constantly reminded that there's all these things to do. Of course, you can tag them or put them in folders, but it's nice when those tags/folders then let you know they're due.
I've been trying to just keep my inbox clean, with varying degrees of success. I could see how snoozing would be useful too.
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.
I built a repository like Evernote where you can email and text your content for saving. Butternote.com
It will be interesting to see how and if Context.io (http://context.io) starts to use this API. We use Context, and it's a fantastic product.
We're working on making all of our features togglable. Stay tuned.
There is clearly some overlap in use case and we're working on making that better but wanted to get out Snoozing as soon as possible.
If it's useful to anyone: http://pastebin.com/c4JvjNef
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.
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.
EDIT: and inefficient
It worked pretty well.
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.
Is it to bypass firewalls in some way ?
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.
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.
> 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.
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?
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.
Being able to replace my current IMAP client code - full of hacks to convert internal ids to Gmail ids and format conversion issues - into a couple of HTTP calls sounds great to me.
Granting that level of access with no fine-grained control to 3rd party apps seems insane to me. I predict at least a couple major security incidents in the future.
Not sure why they really need an API though. Seems to me like it would have been a better solution to stick to the IMAP protocol and allow an alternative method of authorization. For example an application would request access to your email, then they'd get an access token and use that to authenticate with IMAP. They could then try to delete an email with the IMAP protocol and if they hadn't requested that scope they're receive an error.
HTTPifying everything seems to be a trend, not sure what the real purpose is - if anything it's just making things less open.
This was the reason Google provided for not supporting Git in Google Code initially. They do support git now though.
In fact, at least the connotations I have with IMAP/SMTP: "shit still gotta learn that before I can start". Even though it would probably not even take a couple hours to get started.
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 XMPP and Talk[0]. I really hope this isn't the first step towards that.
As bpodgursky pointed out, this sentence is troubling:
> 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
Emphasis mine.
[0] I admittedly had no evidence for this speculation before today, just a worry.
"make it easier for other Internet applications to use information in your email"
"It will replace IMAP"
First one seems par for the course, the second one doesn't seem to be reflected in the Google blog post [1]. Certainly for the moment, thankfully, it looks like IMAP is staying:
"The Gmail API should not be used to replace IMAP for full-fledged email client access" [2]
[1] http://googleappsdeveloper.blogspot.com/2014/06/introducing-... [2] https://developers.google.com/gmail/api/
Trustworthy-seeming companies like, say, Google?
Everyone's fine with the former, but the second should always give people the creeps.
http://web.archive.org/web/20120421075522/http://www.prescod...
Until then I'll probably run out of "quota units" polling the thing..
I then have my Twilio number added as a favorite contact in iOS Phone app thus bypassing the scheduled Do Not Disturb feature. I will continue to get calls every 3 minutes until I answer the call and press 5. That's my "shit hit the fan" alarm.
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.
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
However, I feel the access control is very coarse grained. For example, RSVP widget needs access to only event related emails and itinerary needs only travel booking emails, but the API spec does not allow for such fine grained control.
IMO, given that google is able bucket-ize emails into travel booking, event, etc., and even user-defined labels for any custom grouping, allowing access on such buckets would be nearly as useful and much more user-privacy friendly. For example, an accounting app could still access invoices from my inbox to update my accounts automatically. Google could even push for microformats kind of annotation to make emails semantically richer.
It'd be interesting to see what kind of limits (no. of calls, concurrency etc.) that Google has put on the API. Has anyone trying this out hit of any of these issues yet?
Technical users can and will block access to portions of the API during authenticatcaion, but what about people like my parents? They might very well login, giving full permissions to the app, seeing that it's a trusted google URL while not knowing what they have done.
This is going to open a new can of worms.
EDIT: see https://developers.google.com/gmail/api/v1/reference/users/t... and look at the 'q' parameter