7 posts tagged “api”

Overnight Flickr launched their video support, which I'm sure you can read about everywhere else. I'd like to note (as much for myself as anything) how to handle videos in the API.

As with the main site, videos are treated just as funny photos. As kellan explained on the Flickr API group, the API does just the same thing. There's a new "extras" parameter, "media", which returns either "photo" or "video". What isn't fully explained on the thread is how to display a video as a video, rather than as a static thumbnail (the way Flickr themselves do on, for example, pool pages).

The answer is to use the embedding code shown with each video. (You'll need to be logged in to see that page.) Seasoned API users will note that the photo ID and secret are in the code that Flickr gives you, so it looks like it'll be easy to check the media attribute for a photo, and either show just the image, or use the Flash code (with the appropriate substitiutions) to show a playable version. Unfortunately, if you can't figure out the aspect ratio of the image (typically by using the o_dims extra argument to methods like flickr.photos.search - and yes, it works for videos), you'll need to do an extra call (to flickr.photos.getSizes) to get those arguments for the <object> tag. (This is a problem for images, too, but I'd be happier leaving height and width tags out of an <img> than an <object> tag.)

In summary, then, supporting videos on Flickr through the API looks as if it should be straightforward, and in fact even if you do nothing then it'll work (albeit with videos treated as images). Nicely done.

Launched today at Etech, Fire Eagle is a new Yahoo service that lets apps easily store and retrieve your location. Its big selling point is that it can take almost any input (postcodes, addresses, cities, lat/long pairs) and then give a heirarchal output to apps, with levels of precision that the user chooses.

Unfortunately, while almost all of these levels ("country", "city", "exact") make sense whichever country you're in, there's one that doesn't. In the UK, "postal" will return a full postcode, which locates you to a building (at best) or a street (at worst). In the US, by contrast, it reutrns a five-digit zip code, which covers about 5000 people, and is obviously far less revealing. (I've no idea what it does outside these two countries, but I'd love to know.)

Now, obviously I can work around this in a couple of ways. Firstly, I could be fuzzier about the location I give to Fire Eagle, but this is silly; then nobody gets the better data. Much better, then, to use one of the other choices that are offered, but this begs the question; why have the postal option at all?

Still, it's early days, and as well as looking forward to seeing how the service (and its uses) evolve, I'm hoping there'll be a few tweaks for international consistency within the service itself.

A year or so ago, whilst writing groupr (RIP), I came up with what I thought was a useful name for something I found myself doing a lot: the API join. I'm fairly sure this is common to a lot of Web (2.0) APIs, but it's especially common with Flickr. For example, take groupr. First, it would do a call to get the groups you're a member of. For each of these, it then fetched the photos in the group. Obviously, this has a problem: as the number of groups you're a member of goes up, so does the number of calls to the API - and each call takes about a tenth of a second. The only way to mitigate this, and the solution groupr used, was to page the groups - and even that leaves you making as many calls as you have groups on the page.

The problem reared its head again when I was looking at doing a ffffound-inspired Flickr favourites app. I wanted to display the usual Flickr size, rather than square thumbnails (as Flickr's own favourites page does). Unfortunately, the standard call to get favourites didn't list the size of the photos, and I really didn't want to spend two seconds fetching them all. Other people have raised similar questions on the Flickr API group discussions; for example, here's one about getInfo and getExif, and here's another about getting photo sizes.

Imagine my surprise, then, when I looked at the documentation for flickr.photos.search and noticed a new argument to the "extras" parameter: o_dims. It turns out this returns the original height and width, and is also available in the favorites methods, so now it's possible to avoid doing those calls, and to embed derived height and width for web-scale images from a single call, even for the 36 or so images on Flickr's version of the page.

Of course, this is simply because the API has now moved the join deeper; instead of being at the API level it's being done inside Flickr (presumably at the database level). In fact, I suspect that last weekend's database downtime may not be unrelated (perhaps it was needed for the launch of Apple TV's Flickr slideshows?). It also doesn't help with the other methods, such as getExif (there's a reason I've moved some of my EXIF data to machine tags, which are fetchable with another extras parameter to many calls).

Facebook, interestingly, allows a SQL-like query language as part of their API access, but I wonder how they deal with queries that could bring the database to its knees. I do notice the line

In order to make your query indexable, the WHERE should contain an = or IN clause for one of the columns marked with a *.

Is that an enforced criteria, or is it merely a recommendation, and do they return long-running queries without results to keep up database performance? It's the sort of thing I'd love to see Flickr add to their API, but I can imagine the problems are far from trivial, and in the meantime, I'm very happy to see one API join bite the dust.

Things you should be able to do with Flickr favourites 1, but can't:

The idea of Hackday London 2007 was, unsurprisingly, to hack. Beforehand I'd had little idea of what to do, but candace managed to come up with a few ideas. Notably, one evening last week she noticed some photos on SpaceWeather.com of the International Space Station, as taken from the Netherlands, and thought that perhaps we'd have a chance of seeing it. We checked Heavens-Above, a venerable satellite tracking/prediction site, and we caught a flyby which included a moment of brightness as the newly-deployed solar panels caught the sun.

Wouldn't it be great, she mused, if it was possible to get messages to your phone when such things were going to happen? As well as ISS flybys, there are also Iridium flares, where the redundant communications satellites reflect sunlight down to the ground, and it'd be nice to be told about those, too. It looked like we had an idea.

Implementing the idea wasn't terribly tricky, either. There are two parts to it. Firstly, there's a scraper for Heavens-Above. We set up a special London account, and wrote a script that authenticates against the site,  and downloads and parses the data tables for the ISS and iridium flares. This goes into a plain text file, with the date and time as one field and the text message to send as the next. Since the data tables list events for seven days in advance, this script doesn't have to run frequently- at the moment it's doing so once a day.

Secondly, there's the sender script, which runs every five minutes. It reads in the data file, parses the date (slightly hackily- I'll need to fix that eventually), and, if the event is within twenty minutes, sends it to Twitter (which we use as it's a simple way of sending SMSes to multiple users). Also - and this is where where the required use of a BBC or Yahoo! API comes in - the script checks the Yahoo feed's "current weather conditions" value, and if it's likely you'll be able to see the event, continues onwards to send it. Otherwise, it doesn't bother (but I do get an email from cron telling me what the weather actually was).

I was able to get all the coding done and put it on my colo before one of the flares that evening, but sadly the weather wasn't quite clear enough and we didn't have visibility in the right direction. Still, we had text messages and a Twitter page that we could point to as proof of a working hack, so we went home. (There's an aside here about the difference between the SF culture and London's more lackadaisical one, perhaps, but it'll have to wait for another day.)

I spent another 30 minutes on Sunday morning tidying up the verbosity of the script (it now only prints, and hence sends email, at the same time it has output to send), and then came the slightly nervewracking presentation, which thankfully seemed to go down well, despite us having nothing really in the way of UI to demo. (One of the best things about Hackday- you don't have to write up yourself...)

That evening I added a feed for SF (and took the chance to comment alongside all the bits of code that needed changing). If you're interested in getting messages for passes Above London or Above SF then get a Twitter account and follow the appropriate user. (Longer-term Twitter users might want to adjust their phone notification settings if they want to get SMSes late at night.)

What's next, then? Well, I've since looked at a Perl module (Astro-satpass) that would have let us cut out Heavens-Above, and possibly opened the door to more customised notifications. In particular, we've made some arbitrary decisions (we don't send flares that don't climb above 20°, for example) and it's really hard to add a new location. It'd be nice to remove those limitations, but doing so introduces a new problem; namely, Twitter is a very easy platform for notifications, although I'm concerned about its reliability and timeliness. Customised messages mean either abandoning it or (ab)using the direct messaging syntax.

It was notable that Twitter was used in a fair amount of the hacks (from the live blog post written during the presentations, at least 10%). I think it'd be a perfect fit for Yahoo, alongside Flickr and del.icio.us, as a developer-friendly site that, perhaps, needs a bit of resourcing behind it to make it truly reliable (and, perhaps, more international; the UK number isn't always cheap). How about it?

Anyway, the two applications/accounts/bots should now run without human intervention (at least until that date hack I mentioned rears its head around Christmas), and hopefully I'll remain inspired to tackle the more complex project of personalised feeds and notifications later in the summer. For now, enjoy spotting satellites.

For a very long time I've been intending to learn a better way of writing web applications. I had a very small potter with the the obvious candidate, but that didn't seem to work out. Screencasts don't make good tutorials, perhaps. There were a raft of Perl MVC web frameworks to look at, but that never quite worked out either.

When Fotango announced a competition - with prizes! - for the best Zimki application, though, I seemed to find enough motivation to do something new. Zimki is a Javascript-based hosted web development service. You write the server-side logic with Javascript, and there's a provided persistency framework, advertise RESTian web services and a choice of templating solutions (Trimpath's JavaScript templates and TAL). There's also a client-side library which uses MochiKit to allow you to make web service calls.

So, what to code? Well, I'd been intending to develop a small web app to keep an eye on the photos in Flickr pools for a while, and this seemed to be the ideal opportunity. Furthermore, Sven-S. Porst wondered if you couldn't get your group memberships in an alphabetical list. Seemed like the idea was sorted out then.

There's an entire other post to be written about the pitfalls I found in developing the app, but I'll have to trawl IRC logs to see what I was complaining about. Skipping to the end, the app got to a state where I was happy to submit it on the closing date of the competition, and here it is: groupr.

It's pretty straightforward really, but there is a bit of hidden complexity. Firstly, any request to the root of the domain checks to see if there's a Flickr authentication token in your session. If not, you're prompted to sign in (and shown a lot of explanatory text about it). If you are, you're directed to the groups page. Then your group list is fetched (and cached), and the main template is displayed.

As this is the first time you're looking at the page, none of the detailed information about the groups (most importantly, the photos in them) are available. I could fetch this all first, then display the page having done so, but that could take a while. Instead, once loaded, the page calls a web service (on groupr itself) that proxies through to Flickr, caches the result, then returns the photo data. (The caching means that, the second time you load the page, it's included straight into the template.) Hopefully this all works slickly enough that nobody really notices the difference between the first (AJAX) load and the second (cached) one.

Unfortunately, if I did this for all the groups I'm in (65 or so), it'd still take far too long, hammer Flickr's picture servers, and possibly swamp the client under the weight of HTML, so only ten groups are shown, with paging through to the other chunks of ten groups.

groupr's still under development; I'm looking at ways of showing more than just the most recent photos in the group, and also at persisting data so that you can get a list of photos you've not seen (somewhat like Flickr's "photos from your contacts" page). It's certainly a fun little app to hack on and a nice enough environment in which to do so. Plus, I'm still waiting to see if I win a prize. Which would be nice.

On Monday evening, I was poking around with various APIs trying to configure Flickr to post photos to Vox. Now, the former claims to be able to post to the Atom API, and Vox claims to have one, but when I configured it and tried to test post I got an uninformative error.

Delving deeper, I broke out XML::Atom, the Perl library - originally by the CTO of Six Apart, now maintained by one of their technical folk - and tried a trivial test post, not unlike this example in Ben Hammersley's book. It didn't work either, with the somewhat baffling error "200 OK".

Doing more research, it seems that a lot of clients - Ecto, for example - have trouble with Vox. There is an internal Six Apart project for a Mac OS X based TypePad/Vox uploader, called Fence, but it's not finished, and doesn't work with 10.3. After a bit of headscratching, I decided I'd need to spend far more time than I have to figure out what was up, and left it.

This morning I discovered that Flickr have explicitly added Vox as a supported blog type. This just confirms to me that there's something odd about Vox's Atom API. Perhaps I shouldn't be surprised by this: it's got nowhere near the adoption or longevity of the competing XML-RPC weblog APIs, and only a couple of months ago Anil Dash noted that it was still niche: "the Atom API hasn't gotten finalized in the way that feed format did" and "Atom will probably show up somewhat later in new tools using blogging APIs".

So, Team Vox, one thumb up for Flickr picture posting, since my earlier complaint about posting is now void, but one thumb waggling uncertainly, since the Atom API is obviously - to use the apparently industry standard term - "funky". Here's hoping it gets sorted out soon.