Live data from Hacker News

Gmail API

developers.google.com

81–90 of 147 posts

Re: Gmail API

#81
post #70
post #56

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.

There is also our product, FollowUp.cc (https://followup.cc). We've been around for a little over 7 years!

Re: Gmail API

#82
post #54

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

Depends on your messaging volume and typical message size. For some types of apps it won't matter because the volume is small; for others it won't matter because the payload is huge. But you get battle-tested federation, scaling, server discovery etc. nearly free.

Re: Gmail API

#83

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…

Aleem, this is great to see. We at FollowUp.cc (https://followup.cc) have been doing snoozing for quite a while and have a Chrome extension that does this as well. We are getting close to rewriting our entire extension from the ground up, and this API is definitely going to make our lives easier. Side note, I'm a big fan of Streak =)

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

#84

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…

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.

Serious question: What is the use-case for email as a server communication protocol rather than say HTTP/s ?

Is it to bypass firewalls in some way ?

Re: Gmail API

#85

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.

I've done that twice: First time was when we built a demo registrar platform for ".name". We used Qmail with some custom bits and pieces to distribute messages that were used for things like live updates of the primary DNS server, live updates for a web forwarding service etc. A couple of the guys took the idea much further, and implemented a small library to do things like queue browsing via POP3.

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

#86
post #45

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…

Having spent one year of my life trying to replicate Gmail's interface in a desktop app through IMAP (www.betterinbox.com), I can say with confidence that IMAP is completely unsuited for the Gmail paradigm. If we had this API back when we were working on BetterInbox in 2011, our lives would have been much easier.

Re: Gmail API

#87
post #69

GMail 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?

What is it that you want that a desktop mail client like Outlook or Thunderbird doesn't give you?

Re: Gmail API

#88
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)? 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…

Yeah, I do hardcore archiving and practice inbox 0 as much as possible, and it does alleviate that need. But it's still nice to have the email be at the top just when I get home.

Re: Gmail API

#89
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)? 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…

I'm awful at remembering to do anything. When doing inbox zero, I find it really useful to be able to postpone emails so I get a push notification on my phone when they come back into my inbox. That way I know if there is anything in my inbox, I should look at it pretty soon to decide how to process it (deal with it or postpone it)

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

#90

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…

> 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…

Sounds like you should start using flags instead ("stars" in web-gmail?) Then your todo list should be easily accessible through a filtered list of flagged messages. Most IMAP clients offer this out of the box.
Post reply on HN