For those of you that haven’t seen it already, go look at Fire Eagle. Do it now.
For those of you that don’t quite get it, the point is that it’s a central location-brokering service. You tell Fire Eagle where you are (or set your devices and web apps to tell it), and other applications can, if you allow them, use that data in fun and interesting ways (think auto-geo-tagging of photos on flickr, or mapping where your friends are, to name the most obvious).
Anyway: Fire Eagle really caught my attention and, thanks to my
friendship with the lovely Mr. Coates, I got to play a
little with its API before launch. Whilst it’s not quite finished yet
(the methods to find users of your application within a given area,
within, and to find recent location updates from your users,
are not there at the time of writing), the API and, indeed, website are
The website is friendly, playful, and takes all the hard edges off of the concept of using a web app whose sole purpose is to serve other applications and widgets. It has non-awful markup and CSS (although there are a few things I might quibble with in a code review). The URLs, though…
Oh, the URLs! Whoever came up with the idea of allowing
http://fireeagle.com/my/location/is/Austin%20TX (or, indeed, any other
location, but Austin, Texas is particularly apt for me right
now) is an evil genius after my own heart.
The API has had as much care and attention as the web interface, though: no method is out of place, everything accepts what you’d expect. What’s more, it uses OAuth for authorising third-party applications to access user data (and Fire Eagle allows you to specify what level of granularity you want to allow per-application), so even that is positively simple given the existence of libraries to deal with OAuth for you.
I intend to spend a sizeable chunk of my time over the next few weeks playing with Fire Eagle, both updating my Python API binding and hacking around with various ideas I’ve had for fun, useful little apps using Fire Eagle data.
Now, where was I?