The Daily Ink is the voice of Utata. Yes, your voice, our voices ... all the voices. We'd be tickled pink if our members helped us define that voice. And this, Utatans, would be your chance to do that.
Suggest An InkUtata.org may occasionally excerpt content or use small reproductions of protected images for the purposes of comment, criticism, or education. This use falls under the FAIR USE guidelines in accordance with Title 17 U.S.C. Section 107. We evaluate all fair-use situations on a case-by-case basis.
For more information on Fair UseCal Henderson is a PHP programmer, flickr's Engineering Manager.. and has been known to compare flickr to English trifle.
He's also the author or "Building Scalable Web Sites", which has a really cool looking fish on the cover.
One of Mister Henderson's responsibilities is flickr's "Application Programming Interface", or "API". The API is what allows programs to 'talk to flickr'. Everything from photo uploaders and exporters to flickr toys and, most importantly, Utata Projects rely on this system to work their wonder.
I first met Cal through Game Neverending, the whimsically web based online game that a clever band of web developers were working on before they hatched their flickrish plans.
I found GNE through a friend of mine (tom coates, plasticbag.org) who was friends with Stewart. As soon as I saw it I fell in love with it - partly because of the tech (a whole game! in javasacript/remoting!) and partly because of the quirky style and sense of humor.
As something web based it just seemed obvious that you'd want to tinker with it - poke parts of it until something predictable happened. At that point, web services didn't really exist - the first things I built against GNE were IM/IRC integration for the chat stuff.
The developers played a role in the personality of the game - little bits about them leaking through which made it interesting. After a little while I managed to join their internal developer-only mailing list, due to a security hole. Finding out what was going on inside the company made it all the more engaging ;)
There's the file extension (.gne) and plenty of legacy in the database schema, but no actual code. Some databases are named in the GNE style, which makes it quite confusing, although luckily we avoided the server naming scheme (gne servers were called gne1, gne2, etc). flickr has over 300 servers now so it would get confusing!
The original prototype had a few hundred lines of GNE code in it (node service interface and the DB abstraction layer), but that's all been replaced a few times by now. Nothing is original these days.
Yes and no. The scaling issue with GNE was one of building a message passing infrastructure which would allow everyone to be in one 'realm' - see World of Warcraft for examples of how it's still not easy, even with piles of money. A lesson we learned fairly early on was that if adding another server only gets you 95% more capacity, then you'll quickly hit a ceiling. we design things from the start to scale completely horizontally.
We were grossly unprepared for flickr's growth - we've had to rebuild every piece from scratch at some point to deal with scale. These days we're getting closer to ideal, with multiple data centers and good scaling strategies. Still, running out of physical data center space is still an issue, as silly as that sounds.
The nature of an API is very, very simple - expose the tasks that you can do inside the system. GNE's tasks were very different to flickr's, but both shared the same API structure (as far as GNE had an API...). data manipulation is done via some kind of RPC (remote procedure call) and data can be read either via RPC or data 'feeds' (RSS, etc).
The need for a different philosophy comes at scale - when you're exposing services which might be called thousands of times a second, you need to consider the API on par with the site itself - anything performing badly in the API will affect us as much as anything on the front end site. There's also the security beast to worry about.
People care a lot about their photos - but then plenty of people care a lot about their gaming ;)
I think it's a pretty apt way of describing one of the things that sets flickr apart - The social network. The contact network isn't there as a gimmick in flickr - It's an obviously good way of controlling access without thinking hard about ACLs.
We didn't invent it (livejournal may have), but it's a core part of the flickr model - all permission can be based on your friends. With that we get the network effect, which makes it massive.
As for not being apt - I'm not sure it's ever not :)
The API - It's somewhat my baby and the reason I ended up working here. I think the API is something that really sets flickr apart from other apps and has contributed at least somewhat to it's success.
Otherwise, in Interviews:
Utata Ink is a daily publication edited by Bryan Partington (striatic). Photos used on utata.org are stored on flickr.com and obtained via the flickr API unless otherwise noted. To make a contribution to Ink, please visit Ink Me.