Earlier quoted context omitted.
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.
And a competitor to you would be Follow Up Then which does what you do, I think. ( http://fut.io/ ) I've used it for a very long time, but just switched to the snooze button in Streak. It's slick.
Gmail API
81–90 of 147 posts
Re: Gmail API
#82Earlier quoted context omitted.
I've seen an application in production using e-mails as a message broker. It worked pretty well.
Isn't there a lot more overhead with the headers? Neat idea though.
Re: Gmail API
#83We (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…
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.
Re: Gmail API
#84I 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.
Is it to bypass firewalls in some way ?
Re: Gmail API
#85Earlier 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.
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.
Re: Gmail API
#86I 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…
Re: Gmail API
#87GMail desktop client? Yes please :)
I've been waiting years for something like this. In the meantime, does anyone have any suggestions of third-party desktop applications that sync with gmail?
Re: Gmail API
#88Earlier 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)? 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 real…
Re: Gmail API
#89Earlier 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)? 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 real…
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.
Re: Gmail API
#90Earlier 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…
> 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 infor…