Personally, the "Undo Send" feature is one of my all-time favorites in Gmail. A lot of people are comparing it to an outbox, but while the two are functionally similar, they are psychologically different. The undo send simply gives you a few extra seconds to re-read your email and catch any small errors before sending.
When the feature first launched, I was worried I would eventually adjust to it, and stop re-reading emails before clicking "send". So far, that has not happened - it's effectively a psychological trick that continues to make my emails better proof-read.
JODConverter is definitely a reasonable solution for most applications. You can also write a Python script that leverages OpenOffice's Python UNO API to do the same thing - a basic script that turns Office files into PDF's is only ~20 lines of Python.
For really serious applications, though, you will eventually run in the limits of OpenOffice's support for MS Office formats. If you are very picky (or have a very picky client) about the quality fo the conversions, you'll end up having to use Microsoft Office to do the conversions. This is a lot less pleasant to set up, so I wouldn't do it unless you have to.
Before you build it, you might be interested to know that Scribd (and Docstoc, and others) have long had API's that offer this as a free service. We have seen pretty good usage at Scribd, but never enough to think that we could charge for it.
On the other hand, API's for document sharing sites are more complex and offer a lot of other functionality - this may scare off users who just want the transformation. I could see a market opportunity for a Twilio style API that was very targeted at this functionality. I still don't think you'd make a great deal of money charging for it, but I could see it getting some use.
I had no idea that Scribd could do this. I think I'd rather just use the Scribd API than do it myself, and I can probably use some of the other functionality as well. Thanks for the heads up.
The best way by far is wkhtmltopdf, because it uses webkit to render the page. Most other open source projects use a toy HTML renderer, which is not going to work for in-the-wild webpages.
Thanks for that link. Right now I'm doing something similar using a modified version of webkit2png.py that outputs into PDF instead. I'll have to check this out.
I actually think it is. It'll make it harder to say "we're cheaper than aws". Now people will have to qualify that (we're cheaper than some of s3), which makes the statement much weaker.
So, curious what people think about this. Imagine you were running foursquare. Would you block check.in?
I could see an argument for it. If Foursquare blocked them, it would be difficult for them to gain traction. And as the front-runner in the space, Foursquare is arguably hurt more by aggregator services like Check.in, while its competitors are helped by them.
I think they're completely fine with it. Foursquare has been extremely open about how people use their API and this is what their API is for. In the end I don't think they care how people are checking in. They're still gathering useful location information for businesses which is their real value add.
When the feature first launched, I was worried I would eventually adjust to it, and stop re-reading emails before clicking "send". So far, that has not happened - it's effectively a psychological trick that continues to make my emails better proof-read.