Posts by Evernote

Building Apache Thrift on Mac OS X

If you follow this blog, you’re already well aware that the Evernote API is built on the Apache Thrift framework. Our client SDKs give you everything you need to use the API, so most developers don’t actually have to understand much about Thrift. From time to time, though, somebody wants use our Thrift IDLs to compile their own client-side code. Most of our engineers use Macs, and we’ve found that building the Thrift

Continue reading…

Protecting your data: the broken drives edition

In our blog post “Evernote’s Three Laws of Data Protection”, Phil touches on some of the measures we take to protect your data and our goal of being a trusted place for it. There is much more we do, so I wanted to talk a bit about an important aspect: what happens when hard drives fail? You have probably read stories of people buying previously owned computers and finding they

Continue reading…

WhySQL?

When we describe our overall service architecture to smart people who have been involved in other big services, the two most common questions are: Why is your structured data stored in SQL databases instead of something like [big-data, web-scale, No-SQL platform X]? Why are you running your own hardware instead of hosting Evernote in [cloud service provider Y]? These are both valid and interesting questions. I’ll start with #1 and

Continue reading…

Evernote Indexing System

Evernote Indexing System is designed to extend Evernote search capabilities beyond text documents into media files. Its task is to peruse through those files and bring any textual information into the searchable domain. Currently it processes images/PDFs and digital ink documents, with provisions to extend the service to other media types. The produced index is delivered in the form of an XML or PDF document, containing recognized words, alternative spellings,

Continue reading…

So API Together: Evernote and Thrift

When we started to plan the Evernote service in 2007, we knew that we would need to support both “thin” clients (like web browsers) and “thick” synchronizing clients on the day that we launched. This forced us us to think about remote protocols and client APIs before we built any web GUI, rather than waiting a few months to staple an API onto an existing web service. Our application forced

Continue reading…

  • 1 4 5