61–70 of 147 posts
Earlier quoted context omitted.
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've seen an application in production using e-mails as a message broker. It worked pretty well.
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…
If anyone wants to snooze email without auth'ing your Gmail account, here's one I built in 2008 that's still going strong. http://hitmelater.com/ 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.
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 comp…
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. Unilateral…
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…
This might be big, I was just done complaining about the user interface of the GMail web app. If this means that developers can now effectively create another interface on top of a real GMail API this has the potential to really change things. I can already envision several ways in how I could improve my inbox management and reduce the time spent sifting through emails.
It would be sweet if email, in general, was just a nice RESTful API.
GMail desktop client? Yes please :)
GMail desktop client? Yes please :)
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…
If anyone wants to snooze email without auth'ing your Gmail account, here's one I built in 2008 that's still going strong. http://hitmelater.com/ 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.